Моржовый оператор в Python

[besitzeruf]

Лучшеб гнались за сокращением времени для понимания написанного кода! Строчку мы пишем один раз, а вот читаем гораздо чаще. И каждый раз всматриваться и вникать в каждый символ сильно утомляет… Хнык, хнык :-(

[mSnus]

На русском лучше бы назвали по-другому. А то получается хреновый оператор...

[mister_pibodi]

Лучше бы сделали кошачий оператор, типа =^..^=

[SquareRootOfZero]

Зато там есть анальный оператор (_*_)

[mister_pibodi]

из языка программирования "odin ass", видимо

[baldr]

Если мы попытаемся сделать тоже самое с помощью обычного оператора присваивания, то получим ошибку типа, поскольку num = 15 ничего не возвращает.

Сюрприз: x = y = 4. Все вопросы - только к парсеру Питона. И к авторам, которым, вместо того чтобы расширить возможности оператора присваивания придумали новый недооператор.

while (value := input("Please enter something: ") != ''):

И, конечно, здесь та самая ошибка, которая и возникнет у большинства при использовании этого оператора. Здесь value будет равна либо True либо False. То есть ввод теряется. Нужно либо добавить скобочки, либо убрать "!=".

Моржовый оператор очень неоднозначный и непродуманный. Я сам его начал использовать, но мне он не нравится. Уже много обсуждали его при имплементации PEP.

Лично мое мнение - хватило бы и оператора присваивания, если так уж нужно было добавить эту функциональность. Но раз уж сделали, непонятно почему не сделали нормально:

• if not x := get_value(): - нельзя

• if x:= get_value() and something: - нельзя

• `x = 4 + y := 8` - нельзя (и не надо, но хотя бы было в едином стиле)

Вообще Питон движется куда-то не туда ИМХО. Я считаю что ни к чему были и f-строки, и моржовый оператор и тот ад что будет в Python 3.10 после PEP 634 (Structural Pattern Matching).

[baldr]

Поправка: все что нельзя тоже решается скобочками, но выглядит все равно плохо (ИМХО)

[zazar]

f-строки куда как удобнее и читабельнее прошлых вариантов.

[baldr]

Ну, отчасти соглашусь с вами, но далеко не везде они так уж удобнее.

print("Hello %s" % name)

print(f"Hello {name}")

TEMPLATE = "Hello {name}"
print(TEMPLATE.format(name=name))

Вот три варианта вывода. Второй выглядит короче, но это пока в нем мало содержимого. Добавив текста и, упаси Нортон, каких-нибудь вычислений это все легко превратить в кашу.

Третий вариант наиболее правильный академически - вы определяете где-то шаблон, а потом его несколько раз используете с подстановкой. И как раз этот вариант f-строки совсем не решают. И format() и %-подстановка - решают.

[masai]

Третий вариант для данной конкретной задачи формирования одной строки с подстановкой выглядит намного хуже первых двух.

А для переиспользуемых шаблонов никто f-строки не предлагает использовать.

[vladshulkevich]

Гвидо ушел из комитета

[unsignedchar]

На python можно писать на С. Ок. Но зачем для этого целый специальный оператор?

[masai]

Отдельный оператор нужен как раз для того, чтобы не было тех же проблем, что и в C. Неспроста многие программисты на C предпочитают вместо x == 5 в условиях писать 5 == x.

[inoyakaigor]

А объясните суть этого? Почему именно 5 == x?

[masai]

Если опечататься и написать if (x=5) {...}, то это скомпилируется, но будет работать неправильно. Если ставить число впереди, то при подобной опечатке будет ошибка компиляции.

[DollaR84]

Ну почему только в C. я и в python предпочитаю так писать, хоть у меня эта привычка и перешла из C/C++ в python, но и тут же данный способ может помочь от опечатки. Конечно скрипт запустится, но в таком случае ошибка выпадет в рантайме, но выпадет, чем уже облегчит поиск проблемы, чем когда произойдет присваивание, никакой ошибки не выпадет, но скрипт будет работать не правильно.

[masai]

В Python это неактуально. if x = 5 и if 5 = x одинаково некорректны, и скрипт не запустится.

[DollaR84]

да, точно, спасибо. Проверил, таки не актуально. Значит действительно просто старые привычки

[Zoolander]

как отметили выше, выглядит как лишнее умножение сущностей

уже есть x = y = z = 12
то есть подобный смысл у обычного оператора был, надо было просто его расширить

вообще просто можно обалдеть, насколько создатели языков заняты ерундой — прямо хоть садись и пиши свой.

И да, я знаю, что напишу кучу ерунды для стороннего наблюдателя. Такова драма разработки.

[masai]

Если прочитаете PEP-572, там в конце, как обычно, есть раздел с обсуждением, где рассматриваются альтернативы и доводы против. Среди прочего там есть раздел, в котором написано, почему не стоит использовать знак присваивания, а нужен новый оператор.

Основная причина в том, чтобы избежать путаницы между присваиванием и сравнением. Это может легко привести к труднонаходимым ошибкам. В языке C через это уже проходили.

[masai]

Если мы попытаемся сделать то же самое с помощью обычного оператора присваивания, то получим ошибку типа, поскольку num = 15 ничего не возвращает.

Мы получим ошибку типа не поэтому, а потому что print(num=15) синтаксически выглядит как передача функции именованного параметра.

Какой-нибудь print(end="15") никакой ошибки не выдаст, так как = здесь — это не присваивание.

[mallo_c]

Моржовый оператор удобно для тех, кто перешёл в Python из Pascal.
Например:

(a := 5) #  скобки обязательны
print(a, (a := a + 1))
print(a)

Или для тех, кто пишет на WxPython и использует wx.GridSizer.AddMany:

grid_sizer.AddMany([
    (btnA := wx.Button(panel, label="button A")),
    (btnB := wx.Button(panel, label="button B")),
    (btnC := wx.Button(panel, label="button C")),
    (btnD := wx.Button(panel, label="button "))
], 1, wx.EXPAND)