Комментарии 12
Ерунда какая-то, могли бы нормальный оператор when из Kotlin затащить, он куда прозрачнее и гибче. А эти попытались замутить гибкость очередным if посредине строчки, зачем?
С динамической типизацией ваще мемно сравнивать рандомные структуры по контенту, ещё и когда визуально всё одинаково (твой пример с 1,2,3), а по факту ломается. Математики, которые не умеют программировать, для которых был создан этот язык который должен быть интуитивно понятен, меняет свою суть на 360 градусов.
За статью плюс, а разработчикам минус за архитектуру
Питон семимильными шагами идёт в сторону языка для ИИ. Не для того чтобы на нём писать приложения для ИИ, а чтобы только AI agent мог написать качественную программу. Слишком много конструкций и ловушек. БольшАя часть языка сейчас это борьба с последствиями борьбы за свободную типизацию, за которую сначала боролись. Теперь match который, по словам автора статьи, надо использовать после проверки не слишком ли медленный - то есть надо написать две версии с ним и с if, построить бенчмарки... При том что с if точно быстрее, но после бенчмарков может быть удастся оставить несовместимую с 3.9 версию, которая работает медленнее, но красивая. Тройная работа.
В кейсе 1 скорость анализа кода сразу можно увеличить, отсортировав по if status. А цепочки сложных последовательных проверок - в if оптимизировать можно, тут же остаётся только красота.
И джун-pr на собеседованиях, считающий себя сеньором с хитрыми вопросами.
могли бы нормальный оператор when из Kotlin затащить
А чем гораздо менее мощный и костыльный (если в языке различаются понятия expression и statement — это в принципе приговор) when лучше? Пример есть?
Скопировали из семейства ML почти 1:1. Для меня выглядит абсолютно естественно.
Не верите, даже в базовом варианте match не работает как switch. Попробуйте запустить этот код
x = 1
y = 2
match x:
case y:
print(x, y)в Python есть switch/case
Есть ещё оператор « += » для чисел, строк и других объектов.
А что если вы застряли на 2.7 , что тогда делать ?)))
Так и не понял, зачем эта штука нужна, если я привык уже к if-elif-else. Впечатлить стажеров или джунов - типа смотрите, че знаю. Ну допустим. Остальные зададут тот же вопрос.
Пока наиболее валидным мне кажется только аргумент про читабельность - надо посравнивать.
Статья 4 года лежала в черновиках?
Суть именно в том, что оператор не switch, a match со всеми вытекающими.
Красивое лучше, чем уродливое. Явное лучше, чем неявное. Простое лучше, чем сложное. Сложное лучше, чем запутанное. Плоское лучше, чем вложенное. Разреженное лучше, чем плотное. Читаемость имеет значение. Особые случаи не настолько особые, чтобы нарушать правила. При этом практичность важнее безупречности. Ошибки никогда не должны замалчиваться. Если они не замалчиваются явно. Встретив двусмысленность, отбрось искушение угадать. Должен существовать один и, желательно, только один очевидный способ сделать это. Хотя он поначалу может быть и не очевиден, если вы не голландец. Сейчас лучше, чем никогда. Хотя никогда зачастую лучше, чем прямо сейчас. Если реализацию сложно объяснить — идея плоха. Если реализацию легко объяснить — идея, возможно, хороша. Пространства имён — отличная штука! Будем делать их больше!
Авторы match/case похоже не читали zen of python

Мало кто знает, но в Python есть switch/case: Гид по структурному сопоставлению (match/case) не только для версии 3.10+