Если вы используете язык, который может выдавать бинарные файлы, задача по установке всех зависимостей с правильными версиями является одноразовой: это происходит во время сборки. Это не происходит каждый раз при запуске программы. Более того: этот процесс можно автоматизировать, чтобы результат можно было распространять.
Нет, это не так. Ты код обновляешь от раза к разу, и точно так же собираешь его. «В питоне» есть прекрасная альтернатива процессу компиляции — докер! И ровно все тоже самое получается, только артефакты чуть жирнее получаются, зато уже везде под это готовые системы доставки и оркестрации есть. Т.е. вполне есть себе сборка. А до этого люди и rpm не стеснялись делать.
Каждый раз, когда вы запускаете программу на Python, все зависимости должны присутствовать
Как и в любой другой программе. Например, so/dll библиотеки тоже должны быть часто.
Если один из них внезапно пропал, был обновлен или требуемая версия Python недоступна, ваша программа скорее всего не запустится
Так любой софт работает.
Каждое обновление в цепочке зависимостей любых из используемых нами инструментов, сопряжено со значительными рисками сломать нашу среду сборки
У новых версий появляются несовместимости. Опять же, не питон это придумал, в любом другом языке у тебя есть зависимости от внешних библиотек, которые тоже имеют свойство меняться и ломаться время от времени.
Многие встроенные зависимости неприемлемо хрупкие
Увы, но это спекуляция пока не приведены примеры (многие примеры).
Хотите решать проблемы, возникшие из-за выбора Python?
Если я не хочу, то тогда мне придется решать проблемы, возникшие из-за выбора %LanguageName%.
Если вы используете Python сегодня, я думаю, что вы просто обязаны попробовать сделать несколько небольших проектов на языках, более подходящих для создания простых инструментов, которые работают независимо от того, как настроена ваша система
Пользовался и языки норм. Но когда тебе спустя пару лет надо вернуться к своему проекту на Go, ты внезапно обнаруживаешь, что все зависимости сломались и дико поменялись. У меня от момента первого написания до возврата к таким проектам в язык успели втащить систему модулей, например. Пойду ли я писать о том, что Go не надо использовать? Конечно нет! Потому что все абсолютно нормально.
В крайнем случае, даже Java представляет лучшую альтернативу, поскольку у вас есть возможность создавать файлы «jar», содержащие все зависимости. Не модный, но объективно куда менее хрупкий вариант.
И всё ещё обращу внимание на docker.
Я говорю это, потому что потратил слишком много недель на то, чтобы заставить плохо продуманные инструменты работать, я не увидел значительных улучшений за последние годы
Надо обсуждать конкретные примеры. Пока это звучит как «у меня что-то сломалось, не используйте python».
Разве что, чисто для протокола, я не джавист, и джаву тоже не люблю :]
Простите, приписал лишнего! К джаве, кстати, я спокойно отношусь. Мне кажется, как и у любого языка, у неё есть недостатки и есть свои позитивные стороны и, соответственно, чему поучиться.
Спасибо, что нашли время написать комментарий! Очень приятно, что вы отметили подачу, я именно такой тон хотел задать статье и стараюсь так подходить ко всей коммуникации. Не всегда получается, но я работаю с этим.
Не сочтите за пафос: я не забываю, что я просто человек со своим скромным опытом, которому в данном случае повезло высказать свое субъективное мнение.
Другим языкам желаю развития и успеха, т.к. на мой взгляд, языковое разнообразие даёт возможность нам всем развиваться.
Дядя Боб — это, конечно, специалист, но специалист в ООП и прочих аджайлах, а не в типизации
А кто у нас в принципе признанный всеми авторитет в области типизации? Такой формулировкой можно, по-хорошему, отсеивать вообще любые мнения, включая и собственное.
Ну если говорить об эмпирике и личном опыте — на голом питоне (или жс, или любом другом языке) без типов я писать не могу, моя производительность как функция от объёма уже написанного кода падает экспоненциально и в районе 50-100 строк становится неотличима от нуля.
У нас это не так, у нас все хорошо в районе десятков-сотен тысяч строк. Т.е. тут имеет место проблема личного восприятия языка, а не фундаментальная проблема самого языка.
Например коллеги из Я пишут огромные бекенды в 500+ тысяч строк кода и они у них работают, а сами они довольно продуктивны. К сожалению, не могу рассказать больше, но можете поспрашивать.
куча библиотек была неаннотирована
С этим лучше, но все ещё такое встречается. В целом, это пока не слишком хорошо, но работать с этим можно. Можно и свои стабсы писать для сторонних библиотек при желании максимальной надежности. У нас выходит и без этого.
Ну и я не понял, зачем оно такое надо, если новые проекты можно писать сразу на языках, более дружественных к выразительной типизации и при этом не требующих кучу ритуалов, ассоциирующихся с типизацией у среднего джависта
Вот! Вы, как джавист, не хотите писать на питоне. А питонисты хотят писать на питоне. Аннотации — для питонистов, не для джавистов. И для питонистов они выполняют полностью все возложенные на них ожидания — повышают надежность кода.
Мы относимся с уважением к мнению экспертов в других языках, но для нас польза видна и она есть.
К этим исследованиям (особенно тому самому про проекты на гитхабе) есть методологические вопросы
Как и ко многим другим, доказывающим преимущество статической типизации https://danluu.com/empirical-pl/. Тут я все таки еще опираюсь и на Uncle Bob и на некоторых других. Конечно, тут можно мне впаять аппеляцию к авторитетам, но т.к. поле информации огромно, а на миллион проектов посмотреть я не могу и не смогу, мало что остаётся. В основном, я тут топлю за python, не против других языков :)
Обратно, есть и такое исследование — там брали проекты на JS, выбирали коммиты, чинящие баги, добавляли аннотации типов в окрестности бажного кода, и смотрели, сколько багов поймается (поймалось 15%).
Надо почитать, тут так то просто выводы сходу не сделаешь. Информация как минимум любопытная, спасибо.
Тогда более-менее равное распределение багов по всем языкам будет как раз ожидаемым
Вероятно, ну у нас тут довольно эмпирическое поле, конечно. Исследований, надежных, исчезающе мало, поэтому я предпочитаю не считать, например, что аннотации — припарка от всего, такого точно нет. Я считаю, что они повышают надежность и даже по исследованию выше — это так и есть. Но и без исследований, чисто эмпирически, и я и многие коллеги находим с ними проблемы и почти никогда я не встречаю в наших проектах type error'ы. На нашем коде — точно нет.
о что он под капотом использует (почти всегда) базы данных, не делает что же базы данных backend-ом?!
А почему нет? БД — часть бекенда. Если ты пишешь свою БД — написанный тобой бекенд.
А если я числодробилку в WebWorker-е подключу в браузерной вкладке будет ли это frontend-ом?
Так это фронтенд. Можно сказать, что бекенд фронтенда, если так удобнее. Но код будет крутится на клиенте и формально попадать под определение фронтенд. Даже написан он будет на JS. И заниматься им будут фронтендеры.
Едва ли. Просто косвенное задействование сопутствующих технологий.
Вот тут речь о терминологии. Обычно она размытая, но БД расположена на беке, а вебворкер на фронте.
Про бекенд — у нас бекенд на питоне, делает ML предикшены. Чат-бот. Вот он бек, он слушает рэббит, там весь код нами написан. Я считаю его бекендом и это нормально. При том что на клиентов смотрит сервис перед ним. Все эти термины — про разделение проблем. Ну то есть можно назвать это «глубоким бекендом», можно как угодно, но факт в том, что это крутится в наших контейнерах, пишется нами и деплоится тоже нами. Более того, я общаюсь с нашими датасайентистами и мы пишем общие продукты. Для нас проблемы даже общие зачастую.
Если бы мы называли только front-faced сервисы бекендом, то в этом мире не существовало такого явления как tracing, например!
В итоге сказать, например, что статический анализ аннотаций значительно уступает настоящей статической типизации — было бы не очень корректно.
Моя цитата была такой, пожалуйста, не вырывайте из неё кусок в свою пользу. Значительно не уступает. Он работает в той степени, что хватает бизнесу. У нас очень мало ошибок в рантайме, а связанных с типам около ноля. И у языков со статической типизацией ошибки в рантайме тоже бывают, есть про это и исследования.
Ну вот да, с точки зрения бизнеса я бы не выбирал инструмент где такая важная часть
Несмотря на некорректную цитату, скажу про это: если бы бизнес выбирал только идеальные инструменты, бизнес бы не выбирал ничего, т.к. таких инструментов нет. Выбор бизнеса не про технологии и не про надежность, а скорее про рынок, популярность и наличие специалистов. И с последним абсолютно у всех сейчас проблемы (большой дефицит всех).
Даже у вас в банке, как много сервисов написанных не на python ?
Я возможно создал неправильное впечатление и прошу за это прощения!
Я не хотел сказать, что у нас ВЕСЬ банк на python пишут, или что он у нас главный язык, возможно я создал несколько неправильный посыл.
Питонистов у нас относительно джавистов, мало, как и в любом банке. Конечно же у нас огромная кодовая база на джаве и никто её никуда не девает и от неё не отказывается. Джава здорова, бодра, весела и много крутых джавистов.
А я развиваю питон сообщество, не так давно, буквально второй год и рассказываю почему питон хорош, в том числе, как альтернативный стек внутри, а теперь и снаружи банка. Питонистов у нас в банке много, но далеко не все из них бекендеры.
Да, в 3-й версии Питона появились средства явного указания типов, т.е. авторы языка сделали большой шаг в сторону статической типизации, но на текущий момент эти новые фичи слабо поддерживаются как сообществом, так и интерпретатор довольно лоялен к нарушению типизации (по сравнению со строгими языками).
Проблема в том, что автор, скорее всего, на другом языке пишет. Он смешал вместе аннотации типов и типизацию. Виртуальной машине безразличны аннотации, они существуют сбоку и до нее не доезжают. Типизация в питоне — динамическая, строгая, утиная. Gradual типизация — подставлена сбоку с помощью аннотаций. Так же сбоку подставили Structural sub-typing (typing.Protocol). И работает это все довольно неплохо уже. Mypy стал сильно лучше и дает делает тайп гарды, сужение типов. В целом, по ощущению, чуть послабее всё это развито сейчас чем в TypeScript (в котором все отлично), может и не пройдет проверку на типобезопасность, но надежность кода сильно повышается. Мы type error не ловим в своем коде никогда, например.
И это не всё. Есть выдающиеся проекты — pydantic и fastapi. Они берут аннотации типов и в рантайме из них делают супер строгую валидацию, сваггер, можно даже «типизированные» настройки потреблять из окружения согласно 12 факторам.
Т.е. мы сейчас из аннотаций извлекаем пользу и на этапе статического анализа и динамически, в рантайме.
Но, если ваша программа разрастается до больших размеров, то тут уже IDE часто сдается, перестает помогать и уходит много времени на выяснение типов и доступных методов
Про это писал в статье. Время микросервисов, можно сейчас не раздувать монолиты. К тому же: коллеги из больших и уважаемых компаний, имеют у себя разработки на питоне исчисляемые сотнями тысяч строк кода на питоне. И полет у них нормальный.
На мой взгляд ретурн-тайп и аннотации выглядят как костыли которые ломают принципы языка.
Часто я слышу это от людей, которые на питоне не пишут и зачастую его не любят.
Я смотрю на эти вещи гибко. Эти «костыли» Гвидо почти 20 лет назад описывал ещё, и тогда никому они костылями не казались. Просто у многих людей сложилось впечатление о языке исходя из The Zen of Python, и судят они язык прям строго по нему. Все просто, для всего один путь, красиво, тут def, тут for, тут мы скриптик написали, а дальше отойдите, дайте дорогу «серьезным людям с серьезными языками» :). А зен размещен на странице с говорящим названием https://www.python.org/doc/humor/. Это всего-лишь шутливый текст, а не свод предписаний.
Язык живет и меняется и это нормально, это здорово, да даже прекрасно.
Gradual типизация — здоровый компромисс между статической типизацией и динамической. Можно быстро, понятно, надежно и не надо выбирать из трёх, можно все три.
Никто не отменял языки со статической типизацией, никто не говорит, что они плохие. Просто питон действительно по совокупности факторов тоже теперь сильный игрок, вот о чём я и говорю, о чём и написал статью.
Уступает, так как даже самые древние библиотеки будут использовать статическую типизацию . Например в Java , возьмите любую библиотеку и вы точно будете знать, что вам возвращается и как с этим объектом работать . Основное преимущество статической типизации это четкий контракт взаимодействия для любой версии языка .
Поэтому я и написал — «значительно».
Кроме того, у питона есть ответ на это — .pyi и py.typed, typeshed, теперь types-*
Пока это работает не идеально. В TypeScript тот же types сильно круче, даже у самых мелких пакетов нередко есть *.d.ts.
Вполне возможно, что я не прав и просто хочу из python сделать java ))
Да у языков много общего. Сейчас у питона появился статический анализ, питон компилируется в байт код и исполняется на виртуальной машине...
Довольно часто звучит эта самая обесценивающая формулировка — «всего-лишь аннотации».
Но что это значит? Да, у нас нет прям полноценного «вывода типов» (термин, который связан со статической типизацией, насколько я понимаю), но mypy делает очень неплохой статический анализ и типы всё таки анализирует. В итоге сказать, например, что статический анализ аннотаций значительно уступает настоящей статической типизации — было бы не очень корректно.
А ещё исследования статической типизации часто предвзяты и некорректны, когда клонят все в преимущества статической типизации над динамической.
Т.е. получается и нет четких доказательств, что статическая типизация доминирует как и нет доказательств, что аннотации ей чем-то уступают. Так что я бы не стал их обесценивать, т.к. нет доказательств того, что они хоть чем-то плохи.
Мое субъективное мнение такое: Gradual typing — лучшее от обоих миров. Я считаю, что Python и TypeScript пошли по правильному пути, избрав эту концепцию.
Ключевое преимущество языков с динамической типизацией — скорость разработки. Мы просто быстро пишем код, а аннотации стоят рядом и позволяют сделать из этого кода — очень надежный код. Это именно то, что идеально вписывается в agile мир.
Python за аннотации можно было бы накинуть в другом направлении — mypy все ещё не идеальный инструмент.
Это моя рефлексия, не хотел бы создать неверное впечатление о питонистах. Я вижу, что язык в дискуссиях любят приложить, поэтому высказался, это мое видение проблемы. Могу ошибаться.
Большинство из питонистов, насколько мне известно, не испытывают проблем и не чувствуют себя ущемленными. И правильно, язык то замечательный (кто о чём, а я всё о том же) :)
Я как раз в статье пишу про аннотации типов, они снижают накал этой проблемы. Они завозят gradual typing в python, у нас даже алгебраические типы есть. Ну и дженерики всякие, файналы. Type guards, type narrowing появился вот в mypy. Проблема уже решаемая, инфраструктура питона прокачалась. Там не всё ещё идеально (вспоминаю stubs, typeshed, type-*), но очень неплохо сейчас.
Мы покрываем ими весь код и рекомендуем всем людям в community делать так же.
Да травли то особой нет, питон почти все любят. Но имидж не самый лучший сложился. Поэтому я люблю транслировать свою обратную позицию и на этой теме ловить тухлые помидоры.
Отчасти со школами, кажется, так. Но я вот что думаю: неофиты всегда несут проблемы, но это и благо тоже. Да, конечно, на имидже языка сказывается, но зато есть приток новых способных людей, которые рано или поздно создадут что-то стоящее. В конечном счёте, это хорошо, что школ много.
Про специалистов back-front не поддержу, т.к. я за дружбу фронтов и беков, я сам фуллстек, начинал в 2005 году с верстки сайтов, поэтому для меня бек и фронт — не два разных человека, а голоса у меня в голове :)
TypeScript мне очень нравится, сам пишу фронтенд на нём, можно сказать, мой второй язык. Считаю связку python + annotations + mypy + typescript — очень рабочей.
Но в его системе типов я пока не очень силен, честно говоря, type challenge пока не шибко хорошо идет.
Про валидацию: у нас все схемы написаны на zod, он мне больше почему-то понравился. Наверное, я его в начале потащил из-за safeParse, я прям очень-очень не люблю try-catch в js, а в ts меня от него совсем плохо.
Pypy — сторонний проект, его другие люди делают, поэтому это их личный фан, конечно. Да и, потом, интерпретатор языка на языке — это же просто круто :)
А снизится ли их мотивация после запиливания jit в cpython — вопрос, конечно.
Нет, это не так. Ты код обновляешь от раза к разу, и точно так же собираешь его.
«В питоне» есть прекрасная альтернатива процессу компиляции — докер! И ровно все тоже самое получается, только артефакты чуть жирнее получаются, зато уже везде под это готовые системы доставки и оркестрации есть. Т.е. вполне есть себе сборка. А до этого люди и rpm не стеснялись делать.
Как и в любой другой программе. Например, so/dll библиотеки тоже должны быть часто.
Так любой софт работает.
У новых версий появляются несовместимости. Опять же, не питон это придумал, в любом другом языке у тебя есть зависимости от внешних библиотек, которые тоже имеют свойство меняться и ломаться время от времени.
Увы, но это спекуляция пока не приведены примеры (многие примеры).
Если я не хочу, то тогда мне придется решать проблемы, возникшие из-за выбора %LanguageName%.
Пользовался и языки норм. Но когда тебе спустя пару лет надо вернуться к своему проекту на Go, ты внезапно обнаруживаешь, что все зависимости сломались и дико поменялись. У меня от момента первого написания до возврата к таким проектам в язык успели втащить систему модулей, например. Пойду ли я писать о том, что Go не надо использовать? Конечно нет! Потому что все абсолютно нормально.
И всё ещё обращу внимание на docker.
Надо обсуждать конкретные примеры. Пока это звучит как «у меня что-то сломалось, не используйте python».
Отличная статья, у которой незаслуженно мало просмотров! Спасибо за ваш труд!
Простите, приписал лишнего! К джаве, кстати, я спокойно отношусь. Мне кажется, как и у любого языка, у неё есть недостатки и есть свои позитивные стороны и, соответственно, чему поучиться.
Спасибо за ваши комментарии! :)
Спасибо, что нашли время написать комментарий! Очень приятно, что вы отметили подачу, я именно такой тон хотел задать статье и стараюсь так подходить ко всей коммуникации. Не всегда получается, но я работаю с этим.
Не сочтите за пафос: я не забываю, что я просто человек со своим скромным опытом, которому в данном случае повезло высказать свое субъективное мнение.
Другим языкам желаю развития и успеха, т.к. на мой взгляд, языковое разнообразие даёт возможность нам всем развиваться.
Если вы про квайны, то можно, есть еще интерпретатор питона на питоне.
А кто у нас в принципе признанный всеми авторитет в области типизации? Такой формулировкой можно, по-хорошему, отсеивать вообще любые мнения, включая и собственное.
У нас это не так, у нас все хорошо в районе десятков-сотен тысяч строк. Т.е. тут имеет место проблема личного восприятия языка, а не фундаментальная проблема самого языка.
Например коллеги из Я пишут огромные бекенды в 500+ тысяч строк кода и они у них работают, а сами они довольно продуктивны. К сожалению, не могу рассказать больше, но можете поспрашивать.
С этим лучше, но все ещё такое встречается. В целом, это пока не слишком хорошо, но работать с этим можно. Можно и свои стабсы писать для сторонних библиотек при желании максимальной надежности. У нас выходит и без этого.
Вот! Вы, как джавист, не хотите писать на питоне. А питонисты хотят писать на питоне. Аннотации — для питонистов, не для джавистов. И для питонистов они выполняют полностью все возложенные на них ожидания — повышают надежность кода.
Мы относимся с уважением к мнению экспертов в других языках, но для нас польза видна и она есть.
Согласен. Спасибо!
Graal VM — интереснейший проект!
Как и ко многим другим, доказывающим преимущество статической типизации https://danluu.com/empirical-pl/. Тут я все таки еще опираюсь и на Uncle Bob и на некоторых других. Конечно, тут можно мне впаять аппеляцию к авторитетам, но т.к. поле информации огромно, а на миллион проектов посмотреть я не могу и не смогу, мало что остаётся. В основном, я тут топлю за python, не против других языков :)
Надо почитать, тут так то просто выводы сходу не сделаешь. Информация как минимум любопытная, спасибо.
Вероятно, ну у нас тут довольно эмпирическое поле, конечно. Исследований, надежных, исчезающе мало, поэтому я предпочитаю не считать, например, что аннотации — припарка от всего, такого точно нет. Я считаю, что они повышают надежность и даже по исследованию выше — это так и есть. Но и без исследований, чисто эмпирически, и я и многие коллеги находим с ними проблемы и почти никогда я не встречаю в наших проектах type error'ы. На нашем коде — точно нет.
А почему нет? БД — часть бекенда. Если ты пишешь свою БД — написанный тобой бекенд.
Так это фронтенд. Можно сказать, что бекенд фронтенда, если так удобнее. Но код будет крутится на клиенте и формально попадать под определение фронтенд. Даже написан он будет на JS. И заниматься им будут фронтендеры.
Вот тут речь о терминологии. Обычно она размытая, но БД расположена на беке, а вебворкер на фронте.
Про бекенд — у нас бекенд на питоне, делает ML предикшены. Чат-бот. Вот он бек, он слушает рэббит, там весь код нами написан. Я считаю его бекендом и это нормально. При том что на клиентов смотрит сервис перед ним. Все эти термины — про разделение проблем. Ну то есть можно назвать это «глубоким бекендом», можно как угодно, но факт в том, что это крутится в наших контейнерах, пишется нами и деплоится тоже нами. Более того, я общаюсь с нашими датасайентистами и мы пишем общие продукты. Для нас проблемы даже общие зачастую.
Если бы мы называли только front-faced сервисы бекендом, то в этом мире не существовало такого явления как tracing, например!
Более того, термины всё таки неточно определены, они про разделение концептов. Вот, например softwareengineering.stackexchange.com/questions/415908/is-the-database-part-of-the-backend целое обсуждение на тему БД — это бекенд или нет. Однозначного ответа нет, хотя многие склоняются к моему видению.
О, писал на php 6 лет когда-то.
Моя цитата была такой, пожалуйста, не вырывайте из неё кусок в свою пользу. Значительно не уступает. Он работает в той степени, что хватает бизнесу. У нас очень мало ошибок в рантайме, а связанных с типам около ноля. И у языков со статической типизацией ошибки в рантайме тоже бывают, есть про это и исследования.
Несмотря на некорректную цитату, скажу про это: если бы бизнес выбирал только идеальные инструменты, бизнес бы не выбирал ничего, т.к. таких инструментов нет. Выбор бизнеса не про технологии и не про надежность, а скорее про рынок, популярность и наличие специалистов. И с последним абсолютно у всех сейчас проблемы (большой дефицит всех).
Я возможно создал неправильное впечатление и прошу за это прощения!
Я не хотел сказать, что у нас ВЕСЬ банк на python пишут, или что он у нас главный язык, возможно я создал несколько неправильный посыл.
Питонистов у нас относительно джавистов, мало, как и в любом банке. Конечно же у нас огромная кодовая база на джаве и никто её никуда не девает и от неё не отказывается. Джава здорова, бодра, весела и много крутых джавистов.
А я развиваю питон сообщество, не так давно, буквально второй год и рассказываю почему питон хорош, в том числе, как альтернативный стек внутри, а теперь и снаружи банка. Питонистов у нас в банке много, но далеко не все из них бекендеры.
Проблема в том, что автор, скорее всего, на другом языке пишет. Он смешал вместе аннотации типов и типизацию. Виртуальной машине безразличны аннотации, они существуют сбоку и до нее не доезжают. Типизация в питоне — динамическая, строгая, утиная. Gradual типизация — подставлена сбоку с помощью аннотаций. Так же сбоку подставили Structural sub-typing (typing.Protocol). И работает это все довольно неплохо уже. Mypy стал сильно лучше и дает делает тайп гарды, сужение типов. В целом, по ощущению, чуть послабее всё это развито сейчас чем в TypeScript (в котором все отлично), может и не пройдет проверку на типобезопасность, но надежность кода сильно повышается. Мы type error не ловим в своем коде никогда, например.
И это не всё. Есть выдающиеся проекты — pydantic и fastapi. Они берут аннотации типов и в рантайме из них делают супер строгую валидацию, сваггер, можно даже «типизированные» настройки потреблять из окружения согласно 12 факторам.
Т.е. мы сейчас из аннотаций извлекаем пользу и на этапе статического анализа и динамически, в рантайме.
Про это писал в статье. Время микросервисов, можно сейчас не раздувать монолиты. К тому же: коллеги из больших и уважаемых компаний, имеют у себя разработки на питоне исчисляемые сотнями тысяч строк кода на питоне. И полет у них нормальный.
Часто я слышу это от людей, которые на питоне не пишут и зачастую его не любят.
Я смотрю на эти вещи гибко. Эти «костыли» Гвидо почти 20 лет назад описывал ещё, и тогда никому они костылями не казались. Просто у многих людей сложилось впечатление о языке исходя из The Zen of Python, и судят они язык прям строго по нему. Все просто, для всего один путь, красиво, тут def, тут for, тут мы скриптик написали, а дальше отойдите, дайте дорогу «серьезным людям с серьезными языками» :). А зен размещен на странице с говорящим названием https://www.python.org/doc/humor/. Это всего-лишь шутливый текст, а не свод предписаний.
Язык живет и меняется и это нормально, это здорово, да даже прекрасно.
Gradual типизация — здоровый компромисс между статической типизацией и динамической. Можно быстро, понятно, надежно и не надо выбирать из трёх, можно все три.
Никто не отменял языки со статической типизацией, никто не говорит, что они плохие. Просто питон действительно по совокупности факторов тоже теперь сильный игрок, вот о чём я и говорю, о чём и написал статью.
Поэтому я и написал — «значительно».
Кроме того, у питона есть ответ на это — .pyi и py.typed, typeshed, теперь types-*
Пока это работает не идеально. В TypeScript тот же types сильно круче, даже у самых мелких пакетов нередко есть *.d.ts.
Да у языков много общего. Сейчас у питона появился статический анализ, питон компилируется в байт код и исполняется на виртуальной машине...
Довольно часто звучит эта самая обесценивающая формулировка — «всего-лишь аннотации».
Но что это значит? Да, у нас нет прям полноценного «вывода типов» (термин, который связан со статической типизацией, насколько я понимаю), но mypy делает очень неплохой статический анализ и типы всё таки анализирует. В итоге сказать, например, что статический анализ аннотаций значительно уступает настоящей статической типизации — было бы не очень корректно.
А ещё исследования статической типизации часто предвзяты и некорректны, когда клонят все в преимущества статической типизации над динамической.
Т.е. получается и нет четких доказательств, что статическая типизация доминирует как и нет доказательств, что аннотации ей чем-то уступают. Так что я бы не стал их обесценивать, т.к. нет доказательств того, что они хоть чем-то плохи.
Мое субъективное мнение такое: Gradual typing — лучшее от обоих миров. Я считаю, что Python и TypeScript пошли по правильному пути, избрав эту концепцию.
Ключевое преимущество языков с динамической типизацией — скорость разработки. Мы просто быстро пишем код, а аннотации стоят рядом и позволяют сделать из этого кода — очень надежный код. Это именно то, что идеально вписывается в agile мир.
Python за аннотации можно было бы накинуть в другом направлении — mypy все ещё не идеальный инструмент.
Это моя рефлексия, не хотел бы создать неверное впечатление о питонистах. Я вижу, что язык в дискуссиях любят приложить, поэтому высказался, это мое видение проблемы. Могу ошибаться.
Большинство из питонистов, насколько мне известно, не испытывают проблем и не чувствуют себя ущемленными. И правильно, язык то замечательный (кто о чём, а я всё о том же) :)
Понимаю.
Я как раз в статье пишу про аннотации типов, они снижают накал этой проблемы. Они завозят gradual typing в python, у нас даже алгебраические типы есть. Ну и дженерики всякие, файналы. Type guards, type narrowing появился вот в mypy. Проблема уже решаемая, инфраструктура питона прокачалась. Там не всё ещё идеально (вспоминаю stubs, typeshed, type-*), но очень неплохо сейчас.
Мы покрываем ими весь код и рекомендуем всем людям в community делать так же.
Да травли то особой нет, питон почти все любят. Но имидж не самый лучший сложился. Поэтому я люблю транслировать свою обратную позицию и на этой теме ловить тухлые помидоры.
Отчасти со школами, кажется, так. Но я вот что думаю: неофиты всегда несут проблемы, но это и благо тоже. Да, конечно, на имидже языка сказывается, но зато есть приток новых способных людей, которые рано или поздно создадут что-то стоящее. В конечном счёте, это хорошо, что школ много.
Про специалистов back-front не поддержу, т.к. я за дружбу фронтов и беков, я сам фуллстек, начинал в 2005 году с верстки сайтов, поэтому для меня бек и фронт — не два разных человека, а голоса у меня в голове :)
TypeScript мне очень нравится, сам пишу фронтенд на нём, можно сказать, мой второй язык. Считаю связку python + annotations + mypy + typescript — очень рабочей.
Но в его системе типов я пока не очень силен, честно говоря, type challenge пока не шибко хорошо идет.
Про валидацию: у нас все схемы написаны на zod, он мне больше почему-то понравился. Наверное, я его в начале потащил из-за safeParse, я прям очень-очень не люблю try-catch в js, а в ts меня от него совсем плохо.
Мне кажется, что никто не знает пока, т.к. это только декларация о намерениях.
В теории можно полагаться на это: https://docs.google.com/presentation/d/1_cvQUwO2WWsaySyCmIy9nj9by4JKnkbiPCqtluLP3Mg/edit#slide=id.gd63e3f4a32_0_173 «Probably more like luajit than JVM, but I’m just guessing at this stage»
Pypy — сторонний проект, его другие люди делают, поэтому это их личный фан, конечно. Да и, потом, интерпретатор языка на языке — это же просто круто :)
А снизится ли их мотивация после запиливания jit в cpython — вопрос, конечно.