В питон завозят паттерн-матчинг

прекрасно же

ну наконец-то! джва года ждал!..

Кстати, если я правильно понял, это также может быть использовано и как switch case, который некоторые так хотели завезти в Python

Да, я вечно забываю что в питоне нет даже switch.

паттерн-матчинг

Лишнее это.

def is_tuple(node: Node) -> bool:
    return isinstance(node, Node) and node.children == [LParen(), RParen()] and True or False

Не нужно и не питонично же. Хотя постойте, после того как осуждаемая фича попадает в питон, она автоматически становится питоничной.

это также может быть использовано и как switch case, который некоторые так хотели завезти в Python

Это ересь tmtowtdi! Не бывать такому никогда в нашем уютном простом питончике. [Прошло n лет...] Наш свитч самый правильный свитч!

Если от конкретной реализации фичи на питоне таких, как ты, выворачивает наизнанку и начинается кровавый понос, то фича однозначно считается питонячей, pythonic (c).

Иди дальше пиши паттерн матчинг на ифах, клоун. Как гуру вам завещал.

БА-БАХ!11

:-)

Это совсем другое поведение.

case Node(children=[Leaf(value=«(»), Node(), Leaf(value=«)»)]):

это они типа синтаксис разбирают что ли, если записано как «(v1, v2)» и скобки круглые, то это тупля? :)

огонь ))

Кашу мас... эээ... говно фекалиями не испортишь.

А вобще, после того как хипстеры выгнали Гвидо, судьба пистона была предрешена.

Ну наконец-то.

А что Гвидо? Ведь это именно из-за него питон такой куцый, и отстал на десятилетие от современных ЯП. Как только он свалил, началось какое-то развитие.

Кто бы мог подумать, ещё лет 5 назад, что питон получит типизацию и функциональщину.

Так это же было очевидно, вся скриптуха пытается в типы сейчас.

Многострочные лямбды-то завезли?

А давай теперь второй case опиши.

Я бы хотел матчинг по типу аргумента и чтобы (в этом случае) было три is_tuple, но, наверное, нужно на другом языке писать.

А зачем в питоне типизация? Главная его сила - динамика, чтобы с типами не морочиться.

Это не паттерн-матчинг, а перегрузка функций.

Перегрузка это по типу и числу аргументов. А пм - это по значению.

пм тоже по числу присутствует, просто плейсхолдер неважности для этого введен во все эти матчиговые конструкции.

Проблема языков с жесткими рамками и невозможность менять себя непротиворечивым способом просто создавая поддиалект языка. Ну или переписывать ломать совместимость, или заворачивать в сахар который на этапе «выполнения» будет рассахариваться в какую-то конструкцию на более старой версии языка. А у альтернативы, наоборот проблемы с фактом того что можно понаписать диалектов которые потом друг с другом не подружишь.

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

В перле и руби тоже типов нет и никто не страдает. Зачем они в питоне, если это динамический язык?

Потому что питонята хотят нормальное автодополнение IDE, такое, какое есть у C/Java/C#/C++.

Гвидо все правильно делал в рамках того, что задумывал делать, просто потом набежали модники@оптимизаторы, хорошо что он их бросил самих возиться в том, что они сейчас там делают.

Просто разные подходы имевшие разные плюсы и минусы.

Зачем из питона делать java? Ясно, что он создавался для других целей. А все эти попытки «улучшения» выглядят как седло на корове. Корова никогда не станет лошадью.

Вообще-то, этот PEP предложен в том числе и самим Гвидо

Так это ж по сути просто сахарок. Как написано в пепе, оно раскрывается через новый метод __match__ с помощью isinstance

…and True or False

Стыдоба.

Бесполезная приблуда.

Этот PEP от Гвидо и есть.

В перле

$, %, @. В ООП расширениях тип почти везде указать можно.

и руби

Crystal

никто не страдает.

Страдают, так как без типов невозможно запилить нормальную IDE, да и постоянно кто то пытается эти самые типы прикрутить.

Это от перла не страдают? Перл это такой язык для любителей жесткого садомазо.

Питон сильно выразительнее Java и дело тут не в динамике. Ну и java это байткод, а питон скриптуха. Хотя я был бы рад Java в нативе.

Кто бы мог подумать, ещё лет 5 назад, что питон получит типизацию и функциональщину

Не вижу типизации и функциональщины. Вижу очередной __randomword__ зарезервированный метод для создания очередного слоя наследия. А если вы прикинете на секунду, сколько объектов нужно будет создавать для проверки «условия», то поймете, что эта конструкция более ущербна, чем тот пример, который она должна была бы заместить. С таким же успехом я могу делать тупо:

def is_tuple(node: Node) -> bool:
    if node.comparemethodname(Node(children=[LParen(), RParen()])):
        return True
    elif node.comparemethodname(Node(children=[Leaf(value="("), Node(), Leaf(value=")")])):
        return True
    else:
        return False

Кстати, если я правильно понял, это также может быть использовано и как switch case, который некоторые так хотели завезти в Python

Да, я вечно забываю что в питоне нет даже switch

Во-первых:

try:
	{
	1: lambda: print("first"),
	2: lambda: print("second"),
	}[val]()
except KeyError:
	print("wrong")

Во-вторых, кто «хотели»? Я пишу уже почти год на JS, в котором «switch» есть с ES5.1, но у меня ни разу не возникала мысль «не, тут нужно вместо условий switch использовать». Конструкции «switch» нет места ни в питоне, ни в JS, потому что смысл ее (быстрый выбор из большого числа условий) потерян. Даже если не брать в рассмотрение оптимизацию, то в C/C++/Java/etc у switch есть функция, как у единственного удобного механизма записи большого низкоуровневого ветвления. Ничего этого не нужно в питоне и JS, где есть высокоуровневые базовые типы, где можно создавать лямбды, где можно засунуть обработчики в числовой/ассоциативный массив, причем, сделать это в одном месте, без необходимости объявлять функции отдельно и как-то передавать в них параметры.

Я соглашусь разве что с тем, что в питоне лямбды калечные с рождения, из-за чего их применение сильно ограничено. И в итоге разговор идет не о том, как починить лямбды чтобы язык наконец стал чем-то похожим на лисп по удобству, а о том, как ничего не трогать и добавить очередной слой мусора в язык.

паттерн-матчинг и функциональщина связаны примерно как анонимус и девелопмент

А вобще, после того как хипстеры выгнали Гвидо, судьба пистона была предрешена

Выгнали или сам ушел? Я бы на его месте свалил еще в нулевых, когда стало ясно, что язык не может дальше развиваться и он будет долго и мучительно умирать, обрастая мхом новых фич.

А что Гвидо? Ведь это именно из-за него питон такой куцый, и отстал на десятилетие от современных ЯП. Как только он свалил, началось какое-то развитие

А вот в этом месте я намерен адвокатировать Гвидо. Вполне возможно, что Гвидо уже в нулевых был готов выкатить новый диалект со всеми исправелнными недочетами. Но! Индусы все равно будут продлжать пользоваться питоном образца 1991 года. Осознаешь ли ты, что базовые типы питона не менялись с тех пор, и даже модули с их реализацией притерпели минимальные изменения? Вроде какого-нибудь tuple или list.

Кто виноват, что мухи выбрали говно? Тот, кто его нагадил?

Многострочные лямбды-то завезли?

И не завезут. Гвидо уже отвечал на эту претензию, чем-то вроде «в рамках существующего языка этого сделать не получица».

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

А лисп тоже неосиляторы делали, что ли? Очевидно, языки с динамической типизацией делают для того, чтобы по пять раз за день их переписывать. Даже ютьюб не спешит от питона отказываться.

Потому что питонята хотят нормальное автодополнение IDE, такое, какое есть у C/Java/C#/C++

Не вижу связи. Если в программе нужно много раз повторять одно и то же, то ее плохо пишешь — автодополнение вызвано ущербностью инструмента, а не просто оптимизацией рабочего процесса. А когда от избыточности ты избавился, то контекст с доступными идентификаторами ты должен черпать из выполняющейся программы. Я еще в 2008 году хотел такое сделать для разработки GUI на анюте, где тоже есть сложное высокоуровневое состояние и где по мере усложнения приложения отображаемое в графическом редакторе становится всё дальше и дальше от вида выполняемого приложения, но так и не придумал приемлимых путей реализации, которые давали бы какое-то преимущества над уже имеющейся практикой (перекомпиляция—запуск—правка исходников—перекомпиляция—запуск—etc).

Завезите в питон норм REPL, и не нужно будет больше никаких автодополнений. В идеале для этого нужна фича «сделать шаг назад», которая никогда не будет реализована в CPython потому, что он насквозь пронизан сишными функциями с побочными эффектами.

Питон сильно выразительнее Java и дело тут не в динамике. Ну и java это байткод, а питон скриптуха. Хотя я был бы рад Java в нативе

Java в нативе есть, это на самом деле не такая большая проблема. Намного более серьезная проблема — это сделать нативную жаву быстрой. JIT-компилятор инлайнит, делает переменные локальными по факту выполнения, замещает составные объекты скалярами. Например, если у объекта есть метод с модификатором «synchronized», но объект доступен только одному потоку, то synchronized можно смело выкинуть — но компилятор сможет узнать это только во время выполнения. А иначе у тебя десяток машинных команд в регистрах из горячей функции превращаются в несколько вызовов функций с созданием объектов в куче, с потенциальными кэш мисами, малой сборкой мусора, и прочими радостями, больно бьющими по производительности.

Как вариант — можно было бы сделать компилятор, который бы прекомпилировал все возможные варианты оптимизаций и подключал их по необходимости. Но это уже очень близко к поведению JIT-компилятора, и обычно такая задача решается путем сохранения состояния работающий JIT-компилированной программы для последующего запуска.

Завезите в питон норм REPL, и не нужно будет больше никаких автодополнений. В идеале для этого нужна фича «сделать шаг назад», которая никогда не будет реализована в CPython потому, что он насквозь пронизан сишными функциями с побочными эффектами.

А в каком-нибудь SBCL компилятор не «насквозь пронизан сишными функциями с побочными эффектами»? А «раскрутка» имеется.

но до сих пор нет лямбд и гоуту

Я пишу уже почти год на JS, в котором «switch» есть с ES5.1

А из ES3 куда switch делся?

до сих пор нет лямбд

Да ну.

и гоуту

И слава богу