Комментарии 78
Большинство предъявленных претензий – это и есть настоящее ООП, как в Smalltalk.
"Выскажу непопулярное мнение – это не добавляет никакой безопасности, она просто дает ощущение безопасности. Если вы грамотный программист, то так или иначе сделаете всё как надо...
Вообще инкапсуляция – это не совсем про сокрытие. Инкапсуляция определяется как «процесс объединения элементов данных и функций в единое целое, называемое классом» или «отделение реализации от описания». Таким образом, номинально в Python всё соблюдается более чем верно."
Я всегда считал, что инкапсуляция еще и про то, чтобы не допустить некорректное взаимодействие с классом, поэтому насчет безопасности категорически не согласен. При грамотной инкапсуляции классы приобретают интерфейсы взаимодействия, с которыми легко и просто работать при больших объемах кода.
Речь же не про номинально, а про то, что это дает. А позиция "если вы грамотный специалист - ляпайте везде публичные поля, все равно сделаете как надо"... ну, спорно. Так можно пойти дальше и от функций отказаться - ну, идет у вас везде дубляж, и тут поменять нужно что-то. Сделайте ctrl+F и ищите повторяющиеся куски, вы же грамотный, сделаете как надо.
Erlang might be the only object oriented language because the 3 tenets of object oriented programming are that it's based on message passing, that you have isolation between objects and have polymorphism.
(Joe Armstrong, creator of Erlang)
cmd+f [erlang] - 0 results...
Я со многим соглашусь, но оправдывать что-то в Питоне стремлением избежать избыточности это перебор
Python идёт по пути простоты и убирает всё лишнее. Создатели языка даже конструкцию switch case выкинули, дабы "место не занимала".
По-моему наоборот, всё что угодно в Питоне можно сделать десятью способами, три из которых будут идиоматическими, а семь проклятыми как неправильные.
Буду рад осудить альтернативное мнение в комментариях.
Мелкая опечатка в переводе, доставляющая массу удовольствия)
А статья в целом, конечно – просто наброс. Концовка позволяет понять, что автор вполне адекватен, не религиозный фанатик. Но информации в ней ноль.
А чем пайтон лучше, например, пхп ?
Почему не с версией PHP4 сравнение?
Пхп настолько ужасен, что в бенчмарках производительности пайтон где то аж на 240 месте. А учитывая скорость разработки, популярность языка и качество кода выдаваемое хайскилл программистом, пхп вне конкуренции в вэбе.
Почему не с версией PHP4 сравнение?
Потому что фрактал плохого дизайна и общая корявость PHP никуда не делась.
в бенчмарках производительности пайтон где то аж на 240 месте
Производительности чего? Давайте конкретизировать, бенчмарк в студию.
А учитывая скорость разработки, популярность языка и качество кода выдаваемое хайскилл программистом, пхп вне конкуренции в вэбе.
Совершенно общие слова, которые можно сказать про любой язык.
статья 12 года) 10 лет прошло, вы в своем уме?) предлагаю сравнить тогда с питоном 2.5
Во-первых, отучаемся хамить незнакомым людям.
Во-вторых, если хочется поострить - наберитесь минимальной компетентности для этого. Или хотя бы проверяйте свои утверждения. В 2012 году питон 2.5 был давно неактуален, и в ходу был 2.7, а стандартным для долгоиграющих проектов считался 2.6. Ах, да, и еще был 3.2, который уже был лучше чем 2.7.
В-третьих, конкретику в студию. Может, в PHP что-то капитально изменилось? Исчезли странные языковые конструкции и костыли? Или может повысился средний скилл разработчика PHP? Есть что возразить по поводу указанной статьи? Нет? Я так и думал.
во 1х невежды недостойны уважения;
во 2х раз вы вышли попробовать выйти из невежд, проведите пожалуйста сравнение;
в 3х - у вас что-то вышло слишком много вопросов для п.3:
я? вы и предоставьте конретику, ведь вы же утверждаете, а не я;
даже в 5.5 многое уже поменялось, не говоря про 7й или даже 8й;
про скилы - нет слов) тут и обсуждать нечего - если бы вы понимали о чем пишете, то и не задавали бы этот вопрос;
возражение было в прошлом комментарии;
"Нет? Я так и думал." - вы сами с собой общаетесь, может к доктору?
Еще раз: по существу статьи будут возражения или нет? Вы тут уже достаточно наклоунадили по поводу 2.5, так что теперь я очень внимательно жду от вас оправданий.
Все было четко пояснено в прошлом посту, если вы не способны интерпретировать русский язык, сообщите на каком вам удобней воспринимать, я воспользуюсь гуглом специально для вас.
"Вы тут уже достаточно наклоунадили по поводу 2.5" - вы действительно не понимаете к чему был отсыл? случайно не достойный ответ про уровню вменяемости на ваш комментарий? почему вас ваше сообщение устроило, а мое нет, корреляции не улавливаете? так вот попробуйте подумать - это полезно.
четко пояснено
вы в своем уме?) предлагаю сравнить тогда с питоном 2.5
Я так понимаю, что "2.5" и "вы в своем уме" - это ваши лучше аргументы. Слив засчитан.
Так слились же вы, не желая найти + и -, а тупо распространяя сплетни 10 летней давности, да еще и пытаясь свои проколы перекладывать с больной головы на здоровую, в надежде что кто-то должен за вами вестись и что-то делать. Надеялся что вы поймете, но увы. Пора уходить с вашего уровня, потому что уже 4е сообщение от вас и чувствую, что вы меня уже начинаете задавливать интеллектом.
Может, в PHP что-то капитально изменилось?
вы не поверите - https://habr.com/ru/company/otus/blog/524270/ , https://habr.com/ru/company/otus/blog/524990/
Позовите, когда завезут строгую типизацию.
Почему все всегда сводится к строгой типизации в пыхе? В питоне как будто бы с ней не меньше проблем
Во-первых, потому что нестрогая типизация - источник проблем.
Во-вторых, ваш код на питоне некорректен. Почему вы указали модуль в аннотации? MyPy это не пропустит. Кстати, есть ли какой-нибудь линтер для PHP, который отловил бы подобную ошибку не во время исполнения?
В-третьих, давайте попробуем сложить строку с числом в обоих языках и посмотрим, что получится.
Во-первых, потому что нестрогая типизация - источник проблем.
Не отрицаю, мой поинт был скорее про то, что большая часть упреков в сторону php обычно сводится к этому, но тут как в принципе со всеми языками - "нормально пиши - нормально будет"(с), ведь точно так же можно в typeScript или golang везде писать any, но ведь никто в здравом уме специально себе ноги не отстреливает.
Во-вторых, ваш код на питоне некорректен. Почему вы указали модуль в аннотации?
Не пишу на питоне в прод, поэтому воспользовался документацией и гуглом, чтобы узнать "а как это вообще в питоне делается". Однако с заменой string на str код по прежнему исполняется как на скриншоте.
MyPy это не пропустит.
Да, MyPy такой код не пропускает, тем не менее - во время исполнения это работает без ошибок или варнингов, в отличии от php.
Кстати, есть ли какой-нибудь линтер для PHP, который отловил бы подобную ошибку не во время исполнения?
phpcs + (phpstan | psalm) уже де-факто стандарт для php проектов.
В-третьих, давайте попробуем сложить строку с числом в обоих языках и посмотрим, что получится.
Давайте, как результат - и там и там фатал, что в принципе равнозначно
Так же хочется добавить по треду выше
Исчезли странные языковые конструкции и костыли?
Нет, не исчезли окончательно, но постепенно уходят. Язык становится чище и это радует. В python в свою очередь также есть очень странные вещи, помимо тех что изначально в статье упоминаются.
Или может повысился средний скилл разработчика PHP?
Ну это звучит тупо как оскорбление. Мнение о php сложилось из-за массы плохого кода, написанного начинающими разрабами. Сколько такого плохого кода будет на python спустя пару лет, учитывая тонну курсов "стань middle python разработчиком за 1/2/3 час/день/неделя (нужное подчеркнуть)" - можно только воображать.
нормально пиши - нормально будет
Только зачем пользоваться корявыми инструментами, если можно взять нормальные?) PHP - это легаси, больше он ни за чем не нужен.
Однако с заменой
stringнаstrкод по прежнему исполняется как на скриншоте.
Потому что это аннотация, а не указание типа переменной.
phpcs + (phpstan | psalm) уже де-факто стандарт для php проектов
Ну слава богу, хоть это осилили.
Давайте, как результат - и там и там фатал, что в принципе равнозначно
Тоже неплохо. Так и что, это действительно включаемая честная строгая типизация? Или очередной костыль сбоку, который ломается в каких-то корнеркейсах?
Потому что это аннотация, а не указание типа переменной.
Тогда нужен пример, как правильно писать типы в python
Так и что, это действительно включаемая честная строгая типизация?
С ограничениями (например нельзя средствами языка указать, что "верну массив и 100% это будет массив интов"), но да - php позволяет писать как строго типизированный код, который, если очистить от $ перед переменными, будет почти не отличим от java, так и вырвиглазные one-file'ы вида "index.php на 17К строк, охапка дров и сайт готов". На мое счастье, второе я видел только в постах и комментах с "критикой" php и ресурсах типа govnokod.ru
Тогда нужен пример, как правильно писать типы в python
Так и писать: "var: str". Но это АННОТАЦИЯ. Она не проверяется при исполнении, это просто метаданные. Технически проверку можно сделать рядом, но это никому не нужно, потому что есть mypy.
нельзя средствами языка указать, что "верну массив и 100% это будет массив интов"
Ну ептыть. И какая тогда область применения у этой поделки, студенческие курсачи с калькуляторами? В любом большом проекте будут развесистые типы, а для их проверки средств нет.
Вот блин, как обычно в PHP. Вроде сделали, а по факту полумера. Именно об этом была та статья про фрактал плохого дизайна: что ни возьми - всё недоделано или сделано через одно место.
Так и писать: "var: str". Но это АННОТАЦИЯ. Она не проверяется при исполнении, это просто метаданные.
А, ну то есть без костылей типа pydantic типизацию в принципе не сделать получается. Тогда возвращаясь к началу - в питоне с типизацией проблем не меньше. А то и больше если верить тому что вы ответили.
Но это АННОТАЦИЯ. <...> Ну ептыть. И какая тогда область применения у этой поделки, студенческие курсачи с калькуляторами?
https://www.phpdoc.org/ - тоже аннотация, на которой могу написать что "вот этот аргумент, это мапа из трех значений, 1 это int|float, 2е - объект, который умеет приводить себя к строке, а 3е - это список мап, каждая из которых имеет ключи 'foo', 'bar' и 'foobar'". Умеют ли аннотации python'а такое - не знаю, не проверял.
В любом большом проекте будут развесистые типы, а для их проверки средств нет.
Без комментариев
То есть без сторонних утилит, вообще ни о какой типобезопасности речи не идет.
Какая-то оголтелая уверенность в своей правоте основанная ни на чем и голословные заявления, учитывая околонулевые знания хоть чего-нибудь о php.
Я сразу уточнил, но продуктовый код на python'е и не знаю о его трендах и современных практиках, однако при этом я не засираю язык на основании статей 10ти летней давности.
За сим не вижу смысла продолжать.
без костылей типа pydantic типизацию в принципе не сделать получается
Вы разницу между аннотациями и указанием типов точно понимаете? По-моему нет.
Умеют ли аннотации python'а такое - не знаю
В питоне аннотируется практически всё в любых сочетаниях и с любой вложенностью.
То есть без сторонних утилит, вообще ни о какой типобезопасности речи не идет.
Это просто другой подход. Аннотируете все типы в проекте и при сборке запускаете линтеры. И это все конечно здорово, но вы сами сказали, что даже внутри массива уже проверки не работают. Это детский сад.
Какая-то оголтелая уверенность в своей правоте основанная ни на чем
У меня 15 лет опыта коммерческой разработки, и я прекрасно знаю, сколько стоит поддержка пхп. Насмотрелся, как люди страдают, поддерживая, например, racktables.
Частенько подобные рассказы про "20 лет опыта" и "насмотрелись" идут из частных производственно-цеховых лавочек, где 1-2 балбеса годами врастают в офисные кресла, набирая говнокод за 30К/мес. Иногда это делают даже на каком-нибудь фреймворке 5-летней давности.
В отличие же от них, современные конторы, в которых об IT не только слышали, но и занимаются им, понимают что и как устроено в современной разработке. И используют современные инструменты и методики.
Поэтому оставьте свои 15 лет опыта там, где им место - в первой половине прошлого десятилетия, откуда они и есть. И не загаживайте своим нерелевантным опытом то, в чём не разбираетесь.
Успехов!
Я правильно понимаю, что вместо того, чтобы порассуждать об аннотациях и вообще вести профессиональную дискуссиию, вы решили аппелировать к личности комментатора, потому что вас задели факты?
Мой гитхаб идет первой строчкой в гугле. Можете глянуть, чтобы понять, что ваш комментарий ничего общего со мной не имеет.
Успехов!
При чём тут личность? Я аппелирую к нерелевантному опыту.
Вы можете иметь сколь угодно большой стаж, вы даже можете иметь огромный опыт в разработке (что, на секундочку, не равно стажу). Вы можете иметь акк на гитхабе, даже со сколь-нибудь просматриваемыми репозиториями.
Но пока в гитхабе нет ни одного Вашего проекта на php современной версии и с современными же инструментами, пока Вы не подтвердили, что можете профессионально, объективно и со знанием дела рассуждать на тему php - Ваш опыт не релевантен данной тематике. И все потуги что-то доказать выглядят, мягко говоря, смехотворно.
Смехотворна здесь только ваша нелепая стадия торга, куда вы съехали, как только ваше чучелко рассыпалось в прах.
Далее мы с вами будем говорить только по существу. Ваш коллега выше сказал, что в PHP нельзя указать тип вложенных структур данных, чтобы он проверялся strict types. Это очередная полумера из мира PHP: strict types вроде существует, но по факту во многих случаях бесполезна. Или может мы оба ошибамся и на самом деле strict types в состоянии проверить что-то типа "массива словарей с ключами из строк и значениями из массива интов" (в питоне list[dict[str, list[int]])?
Видите ли, в чем дело. Статья, которую я привел выше, является не столько списком косяков в PHP, сколько демонтрацией их подхода: сделать что-то, решающее маленькую частную проблему, а потом, когда окажется, что оно по факту бесполезно в других случаях, изобретать очередной костыль. Прямо как тот самый молоток с двумя зубцами, но без бойка. Забивать им гвозди все еще можно, но как-то неудобно. Поэтому уделом PHP так и останется легаси. Для новых проектов есть средства получше, где авторы сначала думали, прежде чем бросаться писать код.
в PHP нельзя указать тип вложенных структур данных, чтобы он проверялся strict types
Пример такого на python в тред.
Без сторонних либ или утилит типа pydantic, mypy, etc.
А никто и не говорил, что в питоне это есть. Речь идет вот о чем: в питоне строгая динамическая типизация и тайп-хинты, которые проверяются внешними утилитами. В PHP - недострикттайпсы, которые на самом деле проверяют в рантайме лишь ограниченный набор типов, а для всего остального нужно использовать более сложные внешние линтеры.
Вот и получается, стрикттайпсы в PHP дают вам ложное чувство безопасности и никак не избавляют вас от необходимости использования линтеров с указанием типов в комментариях, замусоривая при этом код. Аннотации же в питоне изначально прикручивались как часть синтаксиса и продумывалась необходимость использования их для вложенных типов.
По итогу в PHP есть два (может и больше) способа указать типы: в комментариях (не проверяются в рантайме) и в коде (крайне ограниченные в реальном применении). Два корявых инструмента.
В питоне аннотации пишутся прямо в коде и доступны в интроспекции, потому что авторы питона включили голову и спроектировали их предварительно так, чтобы можно было описать любые типы динамического языка. В итоге имеем единый способ указания аннотаций, который используется как со статическими анализаторами, так и может быть использован для полноценной проверки в рантайме, если она когда-то будет реализована. Более того, некоторые новые библиотеки уже используют эти самые аннотации для контроля типов и всякой сериализации/десериализации объектов.
А никто и не говорил, что в питоне это есть.
Весь тред строился на том, что "php плохой в нем нет типизации". И вот оказывается в python ее еще меньше и какой ответ на это "а нам и не надо, у нас внешние утилиты есть" - так и у нас есть, помимо того что язык предоставляет. В пересечения и сложения типов python умеет?
ложное чувство безопасности и никак не избавляют вас от необходимости использования линтеров
Заменить в предложении php на python и предложение не перестало быть правдивым.
указанием типов в комментариях, замусоривая при этом код
код который не код, а аннотация, но при этом выглядит как код, располагается в сигнатуре как код - очень удобно, да
Аннотации же в питоне изначально прикручивались как часть синтаксиса
И поэтому появились только в 3.5, ага
В питоне аннотации пишутся прямо в коде и доступны в интроспекции
Ну как бы, аннотации php доступны в рефлексии. И так же используются для сериализации/десериализации объектов уже давно.
По итогу как - в php есть строгая типизация для примитивов и классов, в python - этого нет вообще. Но php все равно плохой потому что "нет строгой типизации". Мда
авторы питона включили голову
и сделали 3ю версию. Если мы оперируем к фракталу плохого дизайна 12го года, легитимно в такое же древнее ткнуть python
оказывается в python ее еще меньше
Почитайте вот, чтобы чушь не нести.
Заменить в предложении php на python и предложение не перестало быть правдивым.
Нет. Потому что питон нигде не заявляет о том, что типы проверяются. Я у вас не случайно спрашивал, точно ли вы понимаете разницу между типизацией и аннотациями типов. Как видно, не понимаете.
код который не код
Это код.
И поэтому появились только в 3.5, ага
Появились тогда, когда в них осознали необходимость. Сели, продумали и сделали.
аннотации php доступны в рефлексии
Так аннотации или все-таки указанные типы? Я могу сделать аннотацию для упомянутого выше списка словарей и получить ее в рефлексии в PHP?
По итогу как - в php есть строгая типизация для примитивов и классов
В питоне строгая типизация есть для всего. Еще раз отсылаю вас почитать статью из первого пункта, чтобы понимать, что такое типизация и с чем ее едят.
сделали 3ю версию
Сделали, чтобы разом избавиться от легаси и неудачных решений. Как показала практика, ход был отличным.
к фракталу плохого дизайна
Я наглядно показал вам разницу в подходе к проектированию языка у пхп и питона. Ключевой момент - полумеры. Но вы, видимо, просто не понимаете, что такое проектирование.
Почитайте вот, чтобы чушь не нести.
Ага, снова 12й - про php прям актуалочка, там же в комментах это и подсветили кстати.
Это код.
Который не исполняется, что делает его не кодом по определению.
Я могу сделать аннотацию для упомянутого выше списка словарей и получить ее в рефлексии в PHP?
Да.
Вообще мне надоело документацию пересказывать - хотите жить в манямире, где php такой плохой и "вот-вот умрет" - ради бога, только не надо оскорблять других при этом. Почитали бы сначала про тему прежде чем всех кругом поливать известной субстанцией.
Я про python ничего плохо не говорил и много раз расшаркивался, что на нем не пишу и могу только примерно догадываться как сейчас правильно - вы же такого в отношении php не можете себе позволить. Почему - не мое дело да и все равно уже.
снова 12й
В разновидностях систем типов что-то значительно поменялось с тех пор?
подсветили
Когда будет полностью строгая типизация, тогда и светите.
Который не исполняется, что делает его не кодом по определению.
Но ведь исполняется. В какой раз подряд спрошу: вы ТОЧНО понимаете, что такое аннотации? :)
Да.
Примерчик, пожалуйста.
хотите жить в манямире, где php такой плохой и "вот-вот умрет"
Я наглядно показал, почему пхп плохой, но аргумент про проектирование вы просто не поняли, а потому пропустили мимо ушей. А что он вот-вот умрет - я не утверждал вообще нигде, так что не надо врать, особенно с кавычками. Мое утверждение - пхп обречен на долгую счастливую жизнь в виде легаси, а начинать на нем новые проекты смысла нет, так как есть инструменты получше.
вы же такого в отношении php не можете себе позволить
Могу, потому что я не программист-на-языке, как вы, и потому что у меня есть опыт с пхп.
Ага, снова 12й - про php прям актуалочка, там же в комментах это и подсветили кстати
Забейте. Как я написал несколькими постами выше, человечек как раз и живёт в начале прошлого десятилетия, с нерелевантным опытом оттуда же. До него бессмысленно доводить знания о современном мире разработки, ибо полный сосуд более не наполнить.
Такому персонажу только и остаётся, что с пеной у рта пытаться показать, как он прошедшее десятилетие не сидел, растрачивая свои былые знания и упуская новые. Когда как, всем окружающим очевидно, что занимался он только тем, что упражнялся в словоблудии, наполнял свои внутренние резервуары помоями (чтобы было, что выплёскивать на собеседников) и пестовал своё эго в слепой вере в своё всезнание и в собственное превосходство над окружающими. :D
всем окружающим очевидно
Вас разве не учили аккуратнее обращаться с квантором всеобщности?
Вообще забавно, как вы мимо ушей пропустили абсолютно всю техническую аргументацию, и теперь настойчево вы прячетесь в манямирке, старательно избивая свежевыдуманное чучелко (после краха последнего), потому что реальный собеседник вам не по зубам. Сразу видно - профессионал :)
Кстати, если вам мой опыт - не опыт, не поделитесь ссылочкой на собственный гитхаб? А мы посмотрим; оценим, так сказать, полноту вашего сосуда.
Тогда нужен пример, как правильно писать типы в python
Да гуглится по первым ссылкам запроса.
Ссылка 1. Там же в начале ссылки на PEP, official docs & code style.
[1] Official docs, typing us(age) [+ examples]: https://docs.python.org/3/library/typing.html
[2] В начале статьи [1]: PEP{NNN}.
У меня такое ощущение, что в этой ветке путают статическую-динамическую типизацию и строгую-нестрогую. Питон, вообще-то, строго типизированный язык
Вы абсолютно правы. У питона строгая динамическая типизация. У PHP же - нестрогая динамическая, буквально худшая типизация из возмоных (с оговорками). Да, есть подвижки в сторону строгости, но не более чем подвижки, которые не спасают от сложных проблем и ни от чего не защищают, кроме как в простых случаях. Увы, особо упертые личности даже после прочтения хабрастатьи про типизацию всё равно ничего не понимают :)
Тут есть один важный нюанс - я как раз за то, чтобы действительно сравнивать, исходя из всего. А это значит, что надо смотреть не только на синтаксис ЯП, но и на его популярность на рынке в конкретной области и на его фреймворки. Потому что вряд ли кто то будет писать на чистом пайтоне или пхп.
Например, складывается впечатление, что ларавель куда популярнее джанго. Почему ?
Потому что у PHP низкий порог вхождения, что позволяет нанять множество кодомакак, которые кое-как слепят вам на ларавеле всё что вы хотите (а потом будете страдать при поддержке).
Вхождения во что? В ЯП или в веб разработку?
И так говорят про другие языки:
js - низкий порог, go - низкий порог, python - низкий порог...
В разработку на ЯП вообще.
Ну обычно входят не вообще, а в конкретную область. Для веб разработки на бэке человек должен освоить ряд общих технологий, помимо синтаксиса языка. Синтаксис ЯПа будет самым легким из всего этого.
И пайтон ничуть не сложнее других языков. И сложность это вообще не есть хорошо и не есть самоцель. Простое лучше сложного - дзен пайтона кстати.
Это всё конечно здорово, но PHP из-за своего корявого дизайна и убогой типизации способствует 1) производству быдлокода 2) большему количеству ошибок, чем другие языки. Это просто факт, подтвержденный десятилетиями существования PHP, и спорить с ним глупо. Веб-макаку легко обучить делать на нам лендинги и легко набрать гору макак в ближайшем магазиностроительном вузе, которые сделают вам онлайн-магазин, но когда это станет большим и сложным проектом, его поддержка усилиями дорогих специалистов превратится в ад.
всем
удачным пиаром во время кризиса пхп 5.2-5.3, все сравнение этих двух языков обычно строится на проблемах в пхп этих версий
Мне вот очень интересно, что в голове у людей, которые заминусовали вопрос "чем пайтон лучше пхп"......вопрос, карл)
Все об ООП в Python хорошо, просто автор немного недостаточно образован и не совсем понимает, о чем он пишет...
Создатели языка даже конструкцию
switch caseвыкинули, дабы "место не занимала"
Добавили в 3.10
Где?
Они добавили Pattern matching. Это далеко не одно и то же
И в чем принципиальное отличие, что можно сделать с switch-case чего нельзя match-case?
Что можно сделать - это неправильный образ мысли. Можно и микроскопом гвозди забивать.
Ну если очень надо найти кто что может - проверка класса объекта в матч кейс питона очень геморно сделано. Мне свитч бы больше зашёл, но нет его в питоне. Свитч это if-else-if-... А паттерн матчинг - это паттерн матчинг.
Вот это имею ввиду - https://peps.python.org/pep-0634/#class-patterns
Ну, КМК, стоит увидеть живой код.
match event.get():
case Click(position=(x, y)):
handle_click_at(x, y)
case KeyPress(key_name="Q") | Quit():
game.quit()
case KeyPress(key_name="up arrow"):
game.go_north()
...
case KeyPress():
pass # Ignore other keystrokes
case other_event:
raise ValueError(f"Unrecognized event: {other_event}")Здесь все читается легче, чем описано в сухой документации, верно? (если я конечно правильно понял, о чем вы)
Так это ж тоже из документации. PEP 636 – Structural Pattern Matching: Tutorial.
По мне, приведенный пример не читается легче.И могу обьяснить почему: В этой конструкции языка используется запутывающий синтаксис. KeyPress(key_name="Q") - в питоне стандартом это инициирование обьекта. KeyPress(key_name="Q") | Quit() это вызов '__or__' объектов. Но только не для pattern matching.
Это не значит, что это плохо.
Да, я привыкну со временем, что создание класса в конструкции case - это не создание класса, а проверка "pattern arguments" передаваемого объекта. Лично мне не нравится то, что в этой локальной области когнитивная сложность кода возрастает. Я приводил запутывающие примеры реального кода на докладе на Pycon DE 2022, где причиной роста сложности понимания был именно Pattern Matching. Спасибо Григорию Петрову за возможность сделать этот доклад и за помощь в подготовке.
Кстати в match поддерживается распаковка последовательностей и сопоставление объектов (по классу и значениям полей)
Мне кажется что вы путаете Pattern Mathing и Conditional Statements. Pattern Matching про сравнение одной структуры данных с другой и не важно что потом произойдёт. Switch/case это про выбор ветки с кодом, основываясь на выполнении условия и не важно как именно он сравнит паттерн матчингом или <, >, ==.
К примеру в языке Elixir в котором Pattern Matching был изначально можно писать и так:defp add_is_trigger_to_options(question, %{task_id: task_id, question_type: :TRIGGER}) do
// код
end
defp add_is_trigger_to_options(question, nil) do
// другой код
end
и вот так:
defp add_is_trigger_to_options(question, task) do
case task do
nil -> // другой код
%{task_id: task_id, question_type: :TRIGGER} -> // код
end
end
в обоих случаях используется паттерн матчинг, но используются разные способы выбора ветки кода для исполнения.
Кроме абстрактных классов сейчас в питоне есть typing.Protocol, который больше похож на интерфейсы в других языках
Про "нет интерфейсов" это конечно сильное заявление. Я уж молчу про Протоколы и Дженерики. Но чем "__iter__" , "__len__" , "__str__", etc, не интерфейсы? Реализация любых из этих интерфейсов даёт возможности использовать стандартные конструкции и builtin функции для взаимодействия с объектами, будь то итерция или доступ к значениям через словарные скобки, сравнение, и т.д.
Автору явно надо углубить свои знания по питону прежде чем писать такое.
Вообще ООП возникло как средство упрощения разработки больших программных продуктов, в основном улучшения модульности. Если в условном C (чтобы было ближе к обсуждаемым временам) мне надо было писать #include somelib.h, а потом дёргать подключенные функции, передавая им на вход сконструированные разработчиком библиотеки типы, то в ООП вместо этого кастомные типы и функции для их обработки собраны в объекты. То, что объекты ООП сопоставимы с объектами реального мира - побочное явление, и нельзя сказать, что этого не было до ООП. Я могу декларировать тип struct duck { int age; bool gender}, и затем экспортировать из библиотеки функции void quack(d duck); void fly(d duck);
Проблема с таким подходом в том, что я показываю всему миру внутренности duck и, что ещё хуже, позволяю их модифицировать. Проблема тут не в дисциплине или осознанности разработчика, а в том, что у меня нет способа сказать пользователю своей библиотеки, что можно трогать, а что нельзя. Также я не мог сказать, какие функции библиотеки предназначены для внешнего использования, а какие нет (static появилось позже) Обернуть это всё в объект - способ сократить размер API, предоставляемого библиотекой, а значит упростить жизнь пользователя и разработку новых версий и миграцию на них - нужно поддерживать меньше совместимости.
Ну вот получается, что нижние подчеркивания в пайтоне и приватные методы в "тру оопшных языках" это не лучше и не хуже друг друга, а совершенно одинаково. Потому что сказать, какие методы можно трогать, а какие нет, нужно именно пользователю кода, которым является человек.
То есть пользователем некоего кода является другой код - клиентский, но пишет то его человек, вполне осознанно обращаясь к методам по их названиям.
И тут нужно задаться вопросом - в каких вообще случаях человек неосознанно, ошибочно может обратиться к закрытому методу?
В случае "тру оопшных языков" по идее только тогда, когда он тупо перепутал названия? И ЯП выдаст ему ошибку - мол вот тебе таблетка для памяти, запрещено.
А в случае с пайтоном? Как вообще можно неосознанно обратиться к закрытым методам, зная, что в языке принято обозначать их нижним подчеркиванием? Никак.
То есть получается, что в пайтоне то наружу ничего и не торчит.
Рассуждаю в меру своего понимания, поправьте, если не прав.
Хорошее, годное замечание. Если вдуматься.
Передача сообщений (то есть взаимодействие).
Почему в Python плохой ООП