LINUX.ORG.RU

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

 


2

4

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

def is_tuple(node: Node) -> bool:
    match node:
        case Node(children=[LParen(), RParen()]):
            return True
        case Node(children=[Leaf(value="("), Node(), Leaf(value=")")]):
            return True
        case _:
            return False

История показывает, что участь любого популярного ЯП - С++ ужас.

https://www.python.org/dev/peps/pep-0622/

★★★★★

Япростофшоке, а если надо вернуть массив, сохранится возможность? А как задать что возвращается [bool, Variant, int]? Чтобы второй результат был произволен

Они еще и case завезли?

ТС, прошу подтверди что не троллишь, что не шутишь, что ссылка не фальшивая

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

Япростофшоке, а если надо вернуть массив, сохранится возможность?

Возвращать массив из функции, которая объявлена как возвращающая bool? Зачем?

tailgunner ★★★★★
()

Нахуа, когда есть erlang?

AUX ★★★
()
Ответ на: комментарий от tailgunner

Для примера указал. Сохранится ли питонятская гибкость при типизации. Вообще, интересно, если будет опциональная типизация

Кстати, что там с GIL

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от I-Love-Microsoft

Сохранится ли питонятская гибкость при типизации.

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

Кстати, что там с GIL

AFAIK, так же, как и раньше. К нему все привыкли.

tailgunner ★★★★★
()
Ответ на: комментарий от byko3y

Вот еще статическая типизация для руби: https://github.com/soutaro/steep. Там сигнатуры в отдельных файлах типа хидеров. Насколько я понял, что-то подобное будет в ruby3. Т.е. никаких аннотаций в коде, но можно проаннотировать интерфейсы вручную или генератором. И type checker будет искоробочный. Вот что он там сможет сам нагенерировать, это любопытно.

bread
()
Последнее исправление: bread (всего исправлений: 1)
Ответ на: комментарий от bread

Ты однострочники на перле видел? Регулярки так то тоже боль, но приходится их использовать, так как лучше ничего нет. Но это вовсе не значит, что они удобные или хорошие.

peregrine ★★★★★
()
Ответ на: комментарий от no-such-file

ML который ЯП мёртв и не нужен. Я понимаю что его в СССР учили некоторые товарищи, которым сейчас за 50, но его место прямо рядом с коболом и фортраном, рядом со смолтоком. Из них всех самым адекватным был последний.

peregrine ★★★★★
()
Последнее исправление: peregrine (всего исправлений: 1)
Ответ на: комментарий от byko3y

Лисп жив только благодаря emacs-у и emacs-ерам. Если этот проект свернётся лисперы тоже исчезнут через несколько десятков лет от старости и новые не появятся. Надеюсь у VS Code и Athom-а получится убить emacs.

peregrine ★★★★★
()
Ответ на: комментарий от byko3y

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

peregrine ★★★★★
()
Ответ на: комментарий от bread

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

Опциональная же штука, хочешь – пиши, не хочешь – не пиши. На читаемость тоже не влияет, т.к. отдельным файлом. Совместимость не ломается.

Не вижу причин для негодования.

OSBuster
()
Последнее исправление: OSBuster (всего исправлений: 1)
Ответ на: комментарий от peregrine

ML который ЯП мёртв и не нужен. Я понимаю что его в СССР учили некоторые товарищи, которым сейчас за 50, но его место прямо рядом с коболом и фортраном, рядом со смолтоком. Из них всех самым адекватным был последний

Да я не спорю, что его сейчас никто не использует. Но историю узнать приятно. И неприятно, когда узнать ее не можешь.

byko3y ★★★★
()
Ответ на: комментарий от peregrine

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

Этот тезис можно поставить по другому «современные популярные технологии разработки и инструменты адаптированы под однопоток». С чем я полностью соглашусь. Что, однако, не значит, что лично ты не можешь использовать удобные инструменты и писать код так, чтобы его было удобно отлаживать и чтобы минимизировать риск ошибок в целом. Современному «программисту» вообще нельзя ни одной ответственной задачи доверить, и то, что он при этом не может отладить многопоток, является лишь следствием тенденции.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Нет, это связано с тем, что за скорость и отзывчивость приходится платить сложностью.

peregrine ★★★★★
()
Ответ на: комментарий от peregrine

ML который ЯП мёртв и не нужен

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

no-such-file ★★★★★
()
Ответ на: комментарий от peregrine

ML который ЯП мёртв и не нужен.

ML это языковая семья типа C-like. И она сейчас переживает ренессанс блпгодаря смузихлебам с reasonml.

bread
()
Ответ на: комментарий от peregrine

Лисп жив только благодаря emacs-у и emacs-ерам

Кложуристы смотрят на тебя с недоумением. Но вообще, конечно, emacs это последний оплот каноничного лиспа.

no-such-file ★★★★★
()
Ответ на: комментарий от bread

Чтобы от регулярок пригорело рекомендую с их помощью почистить пару текстовых датасетов...

peregrine ★★★★★
()
Ответ на: комментарий от no-such-file

Не видел ни одного живого кложуриста, как и емаксера ИРЛ. Вимеров видел.

peregrine ★★★★★
()
Ответ на: комментарий от peregrine

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

И откуда вас таких специалистов берут?

satanic-mechanic
()

Очень радует, в какую сторону развивается Python. Введение опциональной типизации в виде аннотаций и mypy – лучшее, что произошло с Python за много лет.

satanic-mechanic
()
Последнее исправление: satanic-mechanic (всего исправлений: 1)

Знаете, сидел сейчас и думал о моем недавнем опыте общения с питон-индусами. Меня удивило в них нежелание отказываться от каких бы то ни было неудобств питона. Сейчас ковырялся в очередном JS-говне, и меня вдруг коротнуло: это же то же самое, один из тысяч частных случаев, которые вам нужно знать для того, чтобы быть хорошим кодером конкретно на JS для браузера.

Люди, которые научились писать на питоне, сделали депозит в виде изучения мелких бессмысленных особенностей реализации этого языка, чтобы потом получить проценты в виде быстрой реализации очередного из однотипных проектов. Этот опыт совершенно безполезен в других сферах, потому что это знание изначально было исключением. По этой причине они изойдут на говно, пытаясь отстоять безусловное превосходство питона среди альтернатив, в том числе среди альтернативных реализаций питона, особенно если эта альтернатива сводит на нет весь предыдущий опыт изучения исключений.

Конечно, картина с JS-кодерами немного отличается, а именно, отличается она быстрой сменой поколений, когда новоявленные индусы набрасываются на новый фреймворк и начинают кричать «jQuery — это прошлый век», в то время, как индусы ретрограды отвечают «зачем так перетяжелять JS — почему нельзя писать чистый JS безо всяких модулей npm от васяна и компиляции сорцов. Кто вообще придумал компилировать JS в JS?».

После это го сообщения вы поймете, почему PEP с паттерн-матчингом будет принят в питон.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

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

satanic-mechanic
()
Ответ на: комментарий от satanic-mechanic

Любому разумному человеку сложно говорить о безусловном превосходстве какого бы то ни было инструмента, а Python, как язык, уж точно не образец идеала

Вот и я об этом. По этой логике те индусы не являются разумными людьми, поскольку для них недопустимо принятие того факта, что питон фундаментально ущербен, но больше под рукой ничего нет на текущий момент.

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

Есть «ньюансы», а есть implementation-defined языки, вроде PHP и CPython, у которых весь язык — это одни сплошной ньюанс. В том числе по этой причине никто не может создать полноценный CPython-совместимый транслятор.

byko3y ★★★★
()
Ответ на: комментарий от satanic-mechanic

У каждого языка есть куча нюансов

Неверно. Нормальные языки описываются горсткой общих правил, никаких нюансов там нет.

cppsektant
()
Ответ на: комментарий от byko3y

весь язык — это одни сплошной ньюанс

Ты дал подходящую характеристику многим языкам.

cppsektant
()
Ответ на: комментарий от byko3y

Прелесть(в нескольких смыслах) как JS так и Python, что в ядре это совсем другой язык чем его одёжки

у питона например уже древнейший (с 2.2 ваще) https://docs.python.org/3/howto/descriptor.html#:~:text=Descriptors%20are%20a%20powerful%2C%20general,classes%20introduced%20in%20version%202.2.

JS ваще scheme в Си-одёжках с кучей WAAAT(F)

и именно потому что в (особенно в JS) на внешнем уровне есть куча шероховатостей шершавостей и далеко не очевидных логичностей - это и позволяет этим чертам быть селекторами умелости в эти языки.

а по сути всё это тьюрингова яма.

qulinxao3 ★☆
()
Ответ на: комментарий от qulinxao3

Прелесть(в нескольких смыслах) как JS так и Python, что в ядре это совсем другой язык чем его одёжки

В каком еще ядре? Разве JS не имел с самого старта эти безумные базовые операции с типами? А нв «внешнем уровне», вроде реализаций браузера и фреймворков, там не просто шероховатости, там поверхность марса, в которой можно застрять и не вылезти.

а по сути всё это тьюрингова яма

На мой взгляд, организация программы как в виде замыканий. так и в виде сочетаний объектов не тянет на звание тьюринговой ямы, они вполне понятны и удобны с практической точки зрения.

byko3y ★★★★
()
Ответ на: комментарий от peregrine

Надеюсь у VS Code и Athom-а получится убить emacs.

Интересно каким образом они смогли бы это сделать.

skiminok1986 ★★★★★
()
Ответ на: комментарий от cppsektant

Неверно. Нормальные языки описываются горсткой общих правил, никаких нюансов там нет.

Еще раз, я не вижу никакой конкретики, что выше у byko3y, что здесь, какие-то эмоциональные реплики. Давайте в студию пару-тройку нормальных языков без нюансов. И, для проформы, пачку нюансов, из которых чуть ли не полностью состоит Python.

satanic-mechanic
()
Последнее исправление: satanic-mechanic (всего исправлений: 1)
Ответ на: комментарий от satanic-mechanic

я не вижу никакой конкретики

Тогда о чём ты пытаешься спорить? Сказали же - много(> 0) частных случаев в правилах языка.

Давайте в студию пару-тройку нормальных языков без нюансов

А чё не сотню-другую? Или ты поскромничал? Одного вполне достаточно - tcl.

пачку нюансов, из которых чуть ли не полностью состоит Python

Изменяемые объекты vs неизменяемые объекты. Доказывай, что это не нюанс.

cppsektant
()
Ответ на: комментарий от cppsektant

Тогда о чём ты пытаешься спорить?

О том, что я вижу очень спорные утверждения не подкрепленные ничем.

А чё не сотню-другую? Или ты поскромничал? Одного вполне достаточно - tcl.

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

Изменяемые объекты vs неизменяемые объекты. Доказывай, что это не нюанс.

Это не нюанс, а норма в подавляющем большинстве языков. Пытаясь все свести к идеальному минимализму мы неизбежно придем к лямбда-исчислению или формализму такого же рода, красивому в вакууме и только. К слову, TCL не является чем-то таким даже близко.

satanic-mechanic
()
Последнее исправление: satanic-mechanic (всего исправлений: 2)
Ответ на: комментарий от satanic-mechanic

я вижу очень спорные утверждения не подкрепленные ничем

Тебе несколько раз сообщили, что к чему. Прекращай шланговать.

Насчет TCL, давай обсудим обработку бинарных данных или расскажи мне про параллелизм в TCL и его прекрасную и элегантную модель, описываемую «горсткой общих правил»

Там нет частных случаев. Показывай, если считаешь иначе.

Изменяемые объекты vs неизменяемые объекты. Доказывай, что это не нюанс.

Это не нюанс, а норма в подавляющем большинстве языков

Ты там про отсутствие конкретики говорил. Я смотрю, ты прям бог конкретики. Показывай это большинство языков. Потому как в C/C++/C#/Java/Pascal/Go и ещё куче скриптухи изменяемость объектов не зависит только от их базового типа.

cppsektant
()
Ответ на: комментарий от bread

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

у Питона на «внешнем» слое спецом сделано под нубов - не так плотно как в пыхе - где ваще всё грусно.

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

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

qulinxao3 ★☆
()
Ответ на: комментарий от qulinxao3

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

bread
()
Ответ на: комментарий от qulinxao3

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

Я так понял, что для того, чтобы ты продемонстрировал это, тебя нужно отдельно попросить, да?

именно потому что сама команда по сути определеяет всё что происходит и как с аргументами

Это применимо к любой подпрограмме - получается, «любой код на яп с поддержкой подпрограмм это набор возможно не связанных друг с другом подпрограмм-языков». Кому-то кроме тебя эта чепуха говорит хоть о чём-то?

cppsektant
()
Ответ на: комментарий от cppsektant

смотри реализацию стандартной библиотеки которая частью на питоне частью на сишке.

увидишь насколько при всей эволюции и следовательно существенной энтропии сырцов - в cpython достаточно проработанная архитектура существенно ортогонализирующая реализацию внешне не связанных концепций.

крч питон внутрях круче чем внешне кажется

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

такова судьба всякой лингвы-франко.

qulinxao3 ★☆
()
Ответ на: комментарий от qulinxao3

увидишь насколько при всей эволюции и следовательно существенной энтропии сырцов - в cpython достаточно проработанная архитектура существенно ортогонализирующая реализацию внешне не связанных концепций

А тебя не смущает, что вообще факт деления CPython на два мира — это само по себе уже привет. Множественное наследование на уровне питона — одиночное наследование на уровне C API. Обращение к атрибутам по запросу к ассоциативному массиву, которое резко превращается в слоты-указатели в низкоуровневых функциях и даже в прибитые гвоздями вызовы конкретных функций Си. Одна из таких прибитостей — это использование списков в каких-нибудь regular expression, хотя, казалось бы, всё что нужно интерпретатору — это создание списка и добавление элемента, дальше уже нет разницы, какой для этого класс используется.

Ну и вообще, я не совсем понимаю, как неустранимо однопоточная реализация в 2010-2020 может претендовать на «достаточно проработанную архитектуру».

byko3y ★★★★
()
Ответ на: комментарий от byko3y

неустранимо однопоточная реализация

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

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

Высказывание звучит как ересь.

Все будет по обычной схеме, введут дополнительные синтаксические конструкции и реализацию под ними, не трогая весь существующий код, объявят старый подход для достижения конкурентности и параллельности как «deprecated» побуждая писать новый и переписывать старый с новыми конструкциями языка, profit.

abcq ★★
()
Ответ на: комментарий от abcq

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

Вот именно, многопоточность значит переписывание всех стандартных библиотек, писанных на Си, плюс еще некоторых распространенных нестандартных. Это называется «технический долг».

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

Все будет по обычной схеме, введут дополнительные синтаксические конструкции и реализацию под ними, не трогая весь существующий код

Смотря что здесь ты подразумеваешь под существующим кодом. Реализацию стандартных функций для упомянутых тобой языков переписывали под многопоток, однопоточный прикладной код при этом не поменялся, но применить его в тупую для однопотока нельзя.

byko3y ★★★★
()
Ответ на: комментарий от qulinxao3

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

cppsektant
()
Ответ на: комментарий от abcq

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

Спасибо, кэп. Ты не препод часом? Высказывание уж больно характерное.

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

В питоне это помешает сделать гил. Причём здесь время? Показывай «многие языки» с гилом.

Все будет по обычной схеме, введут дополнительные синтаксические конструкции и реализацию под ними, не трогая весь существующий код, объявят старый подход для достижения конкурентности и параллельности как «deprecated» побуждая писать новый и переписывать старый с новыми конструкциями языка, profit.

И новые частные случаи в правила языка. Кроме тебя в этом кто-то видит «профит», а не неизбежное следствие плохо спроектированного языка?

cppsektant
()
Ответ на: комментарий от byko3y

переписывание всех стандартных библиотек, писанных на Си

Получается, GIL – проблема не питона, а Си(: -библиотек его, но всё же:).

DonkeyHot ★★★★★
()
Последнее исправление: DonkeyHot (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.