Как стать автором
Обновить

Комментарии 20

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

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

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

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

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

Если мы попытаемся сделать тоже самое с помощью обычного оператора присваивания, то получим ошибку типа, поскольку 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).

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

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

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

print("Hello %s" % name)

print(f"Hello {name}")

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

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

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

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

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

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

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

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

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

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

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

да, точно, спасибо. Проверил, таки не актуально. Значит действительно просто старые привычки
как отметили выше, выглядит как лишнее умножение сущностей

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

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

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

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

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

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

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

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

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.