Всем привет! Меня зовут Денис Аникин, я тимлид в команде Chat в Райффайзенбанке. А также представитель внутреннего Python-сообщества, так называемый «community lead» (об этом как-нибудь в другой раз). В этой статье я хотел поговорить про отношение к Python среди разработчиков и обсудить все основные претензии, которые очень давно следуют за языком по пятам.
В начале я хочу коротко рассказать про причины этой статьи — она не претендует на статус серьезного исследования, статья, скорее, немного ироничная. И возникла она как ответ на бесконечные камни, летящие в сторону моего любимого языка.
Я часто принимал участие в больших дискуссиях, действительно ли Python можно назвать серьезным языком программирования. Именно это, во многом, и стало причиной для написания этой статьи. Здесь я хочу попытаться донести идею, что как минимум для меня Python — действительно серьезный, без всяких скидок, язык программирования. Заодно я хочу воодушевить тех, кто уже пишет на Python, но начал немного стесняться этого, начитавшись интернета.
Также я вспоминаю нашу внутреннюю шутку, которая сформулирована моим коллегой, Даниилом: «Денис начинает свой понедельник с очередного доклада на тему, почему Python — серьезный язык». Я долго думал над этой шуткой (извините, я не гений), а потом решил: почему бы и не начать с этого статью? :)
Поэтому я хочу поговорить про проблемы Python и обсудить накопившиеся к нему основные претензии.
Динамическая типизация
За динамическую типизацию Python ругали практически все — это одна из крупнейших претензий к нему в среде разработчиков. Но на самом ли деле динамическая типизация — такое уж зло? Как минимум, разработка на языках динамической типизации проще, быстрее и зачастую приятнее — конечно, это субъективный тезис, но он имеет право на существование.
Какой-нибудь JSON-парсер на языке со статической типизацией будет гораздо более многословным и тяжелым в написании, чем на языке с динамической типизацией (ох уж эта элегантная связка orjson и pydantic). Где-то, где мы в Python отобьемся манипуляциями в рантайме, придется подтаскивать большие объёмы кодогенерации.
При этом у динамической типизации есть минусы. Например, нам приходится писать больше тестов, у нас может быть больше ошибок в рантайме при некоторых условиях. У нас динамическая типизация, поэтому до запуска понять, что с типами проблема, мы не сможем. И вроде бы статическая типизация здесь выигрывает.
При этом Uncle Bob говорил, что тесты на бизнес-логику не отменяются статической типизацией, да и в Python теперь типы можно проверять статически с помощью аннотаций и MyPy. Конечно, мы пишем больше тестов и тщательно проверяем бизнес-логику, но, на мой взгляд, это идет на пользу сервисам. Всё очень неоднозначно.
Да, у нас есть gradual типизация. MyPy, typing, аннотации типов — это позволяет нам значительно улучшить качество кода, уберечься от массы ошибок, получить экстрафункциональность языка. Например, в Python нет констант, но с помощью связки typing и MyPy можно получить их аналог. Аннотации в Python можно анализировать как статически, так и динамически: в typing есть интроспекция, появляются проекты вроде Beartype.
На базе аннотаций типов построены современные фреймворки, такие как Pydantic (строгие схемы валидации в рантайме) или FastAPI. Я считаю вот так: Python в связке с аннотациями типов являет нам gradual типизацию и тем самым предоставляет здоровый компромисс между преимуществами динамической и статической типизаций. Он не порождает хтоническое чудовище, каким его часто объявляют в интернете. Напротив, нам дают способ писать и быстро и надежно, здесь и сейчас.
Где-то тут к нам подкрадывается вопрос о типобезопасности. Полагаю, что аннотации типов проверку на типобезопасность не пройдут, хотя вопрос это довольно сложный, не для моего уровня понимания. На текущий момент ошибок типов с MyPy и аннотациями типов я не встречал, но уверен, что где-то при определенном стечении обстоятельств это возможно. Единственное, что видно у нас — увеличение надежности нашего кода (пока мы пишем наши бэкенды, аннотации часто помогают отлавливать ошибки), умение гибридно использовать аннотации и почти никаких type error в коде.
Также стоит вспомнить, что люди, предпочитающие статическую типизацию, часто говорят, что для маленьких проектов динамическая типизация «не страшна», а на действительно больших мы начинаем чувствовать её недостатки.
Честно говоря, пункт уже раздулся, поэтому я просто набросаю свои мысли списком:
Статический анализ хорош везде;
Как мы уже сказали выше, в Python есть статистический анализ, пускай и немного уступающий «настоящему» выводу типов — «настоящей» типобезопасности. Мы используем его в полный рост, и с ним можно писать действительно большие проекты
Мы живем в эпоху, когда микросервисная архитектура очень популярна, поэтому проблема проектов в сотни тысяч и миллионы строк кода уже не так сильна. И накал претензий к динамической типизации, соответственно, куда ниже. Даже если мы их принимаем.
Скорость
Этот аспект языка часто подвергается критике очень многими разработчиками. И если динамическая типизация — сложная и неоднозначная тема для обсуждения, то скорость — то, о чем говорят вообще все.
Если посмотреть на синтетические бенчмарки, то Python часто можно обнаружить в самому низу турнирных таблиц. Многие разработчики считают это Ахиллесовой пятой Python, что не может не сказываться на восприятии языка
Когда обсуждают скорость Python, обычно вспоминают про C++, ведь на нем все бенчмарки выглядят в сто раз лучше, чем на Python. Но если мы начнём разбираться в вопросе, то станет ясно, что скорость Python на данном этапе — не такая уж проблема. Конечно, Python действительно медленный в CPU-bound задачах. И тут у вас в голове возникает мысль — если он такой медленный, то это точно проблема!
На мой взгляд, дело обстоит так. В современной web-разработке полно i/o-bound нагрузки: часто мы принимаем запросы по сети, отправляем их в сеть, читаем из БД, пишем в БД, оперируем с файлами и так далее.
Для этого типа задач у Python есть прекрасный ответ — асинхронный подсет языка, нативный async/await, event loop из коробки и uvloop, для тех, кто хочет ещё быстрее. С помощью этой части Python мы можем эффективно утилизировать ресурсы CPU. А для исключительно CPU-bound в мире Python тоже много «припарок»: multiprocessing, subprocess, Pypy, Cython, Numba и так далее. Поэтому асинхронный Python работает очень даже быстро.
Подведу субъективный итог: многое, если не всё, можно смело писать на Python, а CPU-bound, при необходимости (если стандартная библиотека не тянет), переписывать на более быстрых языках и ставить эти микросервисы-воркеры за очередями сообщений. Разве это не идеальное сочетание?
Язык для новичков
Довольно часто Python считают языком для новичков. Ему учат на каждом шагу, в мире миллион курсов по Python. Топовые блоггеры обещают обучить ему чуть ли не за один вечер, говорят, что все сразу же получают серьезную зарплату, уютный офис и счастливое будущее. На этом слишком радужном фоне за Python прочно закрепился имидж языка для новичков, где достаточно написать пару for и def, объявить несколько переменных — и вот ты уже профессиональный Python-разработчик уровня middle. А потом «перерастаешь» и идешь писать на «серьезном языке».
Это все какой-то интернет-морок, потому что Python, как и любой другой язык, требует освоения, изучения, времени.
В самом языке у нас целая куча всяких знаний, нюансов, сложностей и декларативных частей. Судите сами:
У нас есть протокол итерации. Конечно, можно сказать, что итератор — не совсем часть функционального программирования, что итераторы есть и в других языках. Но я хочу подчеркнуть, что итераторы — это не совсем просто, особенно вначале, особенно когда нам нужно реализовывать свои.
Декораторы. Здесь тебе и функции высшего порядка, замыкания, три уровня вложенности для параметризированных декораторов — слишком много всего для такого «простого» языка. Я сам по началу долгое время не понимал паттерн «декоратор», с трудом писал их. И я знаю, что у многих с этим есть проблемы, это видно как минимум на собеседованиях.
Метаклассы. Классы, создающие классы? Функция type, она же класс? А тип type — тоже type? Все классы создаются type? Популярный сценарий применения — ORM? Можно, пожалуйста, мне другой «простой» язык?
Библиотека functools в полном составе :)
Генераторы. Можно спрашивать на собеседованиях: «А для чего вы используете генераторы?» — и услышать очень много разных ответов. Некоторые вообще не понимают, зачем они нужны. А ведь генератор поддерживает протокол итерации, в него можно слать значения, yield from — ну, сами все понимаете.
Контроль зависимостей. Venv, virtualenv, pipenv, poetry, pip tools, pdm, pipx, pyproject и так далее.
Инфраструктура вокруг Python. Крайне полезно для работы было бы знать, что такое pypa, pypi, psf — а это ещё отдельный пласт знаний.
PEP. Иногда спрашиваю людей: «А что такое PEP?», — и самый частый ответ: «Стандарт кода». Даже опытные разработчики помнят PEP8 в лучшем случае.
Около сотни магических методов. Хорошо было бы в них просто ориентироваться.
Могущественная интроспекция и «мета-язычные» вещи. Runpy, importlib, trace, traceback, gc, inspect, sys, typing.get_type_hints, typing.get_origin, typing.get_args.
Встроенные классы ошибок, методов и типов. Можете выполнить и получите 156:
import builtins; len(dir(builtins)). Это количество встроенных классов ошибок, методов, типов. Желательно помнить многое из этого.Новые вещи. Оператор «морж», pattern matching.
Конкурентное выполнение. Threading с кучей нюансов, multiprocessing, subprocess, свежий communicating sequential processes «паттерн» (PEP 554).
GIL. Комментарии не нужны, но они будут (я не умею лаконично, помогите).
Особые языковые возможности. Dict, list, set comprehensions, generator expressions, например.
Асинхронность. Это отдельный «подсет» языка, где уже целая своя вселенная с кучей пакетов и даже отдельными (не встроенными в язык) концепциями, вроде structured concurrency.
Аннотации типов. Или аннотированный Python — тоже, считай, свой мини-«подсет» языка, вводящий новый понятийный аппарат, и новый вид типизации — структурную саб-типизацию, ближайшим аналогом которой из мира динамической типизации можно было бы назвать утиную.
Динамическая типизация. Строгая (местами «обходимая» полимформизмом, или неявным приведением int к float), утиная типизация, typing.Protocol (про него выше), gradual типизация. Скажите мне — это правда так просто?
И я бы мог ещё продолжать какое-то время. Этот список я составил не для того, чтобы отпугнуть от языка, но мне хочется продемонстрировать, что Python — не такой простой язык программирования. Действительно, на нём легко начать, у него низкий порог первоначального входа. Но это вовсе не язык только лишь для новичков, такое отношение к нему порождает безответственный подход к разработке. Язык взял много хорошего от других, он не простой, со своими плюсами и минусами, очень красивыми местами и не самыми лучшими. И всё это требует освоения.
GIL
Можем сказать, что мы снова про скорость. Когда заходит разговор о тредах и Python, о скорости и Python, сразу на сцену выползает наш любимый и обожаемый GIL.
Ограничения GIL известны всем — в Python при попытке распаралеллить любую CPU-bound нагрузку с помощью тредов, разработчики неизбежно сталкиваются с тем, что в один момент у всегда будет работать только один поток. Тема абсолютно выдающаяся и имеющая за собой такой поток реминисценций, что про это даже немного неловко говорить, — но поговорить нам, всё-таки, в рамках статьи нужно.
Издалека проблема GIL — и сложная, и, как кажется, практически нерешаемая (мы все помним, что на этот счет сказали Гвидо, Дэвид Бизли; UPD: тут недавно вышла статья, говорят о nogil… но давайте не будем об этом).
В современных бэкендах и Python накал страстей вокруг GIL сильно стих — веб-сервисы очень часто по своей природе могут быть асинхронными, а для этого у нас есть множество чудесных фреймворков, вроде FastAPI, поэтому ограничения GIL нас не так сильно касаются. При этом горизонтально мы масштабируемся процессами, как в синхронных бэкендах, так и в асинхронных. У многих есть кубер — и там мы масштабируемся тоже процессами, только над ними стоит абстракция уровнем выше — pod.
Некоторые разработчики спрашивают, зачем нам тогда треды?
В современном Python их используют для одной интересной штуки — на них можно делать wannabe-асинхронный код, при этом не делая асинхронный код, как ни странно. То есть можно написать на тредах что-то, что занимается интенсивной i/o-нагрузкой. И тогда внезапно все станет асинхронным за счет того, что GIL отпускается на i/o-операциях.
Это важное примечание, так как это сложный и неочевидный нюанс работы GIL — он описан в документации, но кто же её читает — шутка :). Но благодаря ему мы можем получить преимущество даже в синхронном коде, а также не блокировать петлю событий, когда у нас возникает потребность вызвать синхронное i/o в петле событий (вспомним про запись файлов, привет экзекьюторам).
Python — «неказистый язык для набрасывания прототипов на Django»
Частое мнение в интернете — Python годен только для быстрого, реактивного набрасывания прототипов на Django, а все остальное удел «серьезных языков» (тм). И это ещe одно, с моей точки зрения, не очень корректное суждение.
Конечно, на Django, на Python быстро набрасывают прототипы — я не буду отрицать очевидного. Но на языке делают не только это, описанное — лишь малая часть возможностей экосистемы Python. Однако быстро прототипирующие люди, использующие язык одним способом, почему-то взяли на себя прерогативу оценивать позиционирование языка по своей сфере. И с этим я не согласен.
В качестве одного из контраргументов можно привести наш выдающийся тулсет для написания тестов, который не мог возникнуть в языке для быстрого набрасывания прототипов за ненадобностью.
Pytest — это прекрасный фреймворк для написания тестов и яркий представитель этого тулсета. Он позволяет выстраивать очень сложные тестовые сценарии с инверсией зависимостей всего с помощью двух инструментов — fixtures и parametrize. С их помощью можно делать очень сложные тесты — подробно изучать производительность и бизнес-логику системы.
В тестировании, помимо Pytest, у нас есть Hypothesis — отличный фреймворк для fuzzy, property тестирования. Фреймворк настолько впечатляет, что недавно, на Python Language Summit 2021, стало известно, что его используют core developer'ы и с помощью него нашли ошибки в PEG парсере самого Python.
Использовать его просто, а результатом являются такие тесты, о которых я раньше только мечтал. В итоге из одного теста у нас получается целая последовательность, которая имеет различные статические проверки, динамические, а также случайно сгенерированные:
from hypothesis import given
from hypothesis.strategies import text
def encode(input_string: str) -> list:
"""Это просто синтетический пример."""
count: int = 1
prev: str = ""
lst: list = []
character: str
for character in input_string:
if character != prev:
if prev:
lst.append((prev, count))
count = 1
prev = character
else:
count += 1
lst.append((character, count))
return lst
def decode(lst: list) -> str:
"""Это просто синтетический пример (2)."""
q: str = ""
character: str
count: int
for character, count in lst:
q += character * count
return q
@given(text())
def test_decode_inverts_encode(s):
"""И здесь мы получаем совершенно невероятный объем тестов. При том,
что повесили 1 декоратор."""
assert decode(encode(s)) == s
Для Python существует библиотека для мутационного тестирования mutmut. Если вы вдруг с ней не сталкивались — посмотрите, это очень интересный инструмент. С его помощью можно проверять ваши тесты через небольшие изменения в коде — я бы назвал это мета-тестированием.
Вообще, в Python есть огромное количество вспомогательных библиотек для тестирования — Faker, Factory boy, Mixer, Seed, куча расширений для Pytest — например, для параллелизации. Поэтому говорить, что Python можно использовать только для быстрого прототипирования на Django — немного некорректно.
Безопасность
Как-то раз нам написали комментарий, что за Java и C# стоят крупные компании, бизнес, а за Python только Гвидо и никакой ответственности нет. Видимо, это означало, что языком пользоваться страшно и от этого он абсолютно несерьезен.
Мне кажется, этот вопрос довольно сложный. Крупные проблемы языковой среды — не такой уж и частый сценарий. Но вряд ли при серьезных проблемах разработчики на Java или C# моментально получат их решение.
А ещё можно вспомнить, что современный софт пишется с использованием огромного количества Open Source библиотек, которые пишутся сторонними разработчиками, лежат в открытом доступе — и баги там случаются часто, а гарантий их исправления нет и быть не может. Тогда как серьезные проблемы Python, в случае их возникновения, точно будут исправлены. К тому же у Python «сжался» релизный график.
Поэтому проблемы у многих языков, как я считаю, общие, — и выделять энтерпрайз-языки отдельно, ставить их выше — не совсем правильно.
Популярность
Популярность языка программирования часто оценивают на результатах рейтингов. Поскольку вокруг них ходит огромное количество споров, я решил проанализировать почти все известные рейтинги по популярности языков.
Причин роста много, но кроме известных, для себя я предпочитаю выделять такую: одна из сильнейших черт Python в том, что он по пути вбирал в себя огромное количество разных парадигм и подходов, зачастую беря из них если не лучшие, то как минимум хорошие куски. Именно поэтому он умудряется быть таким универсальным и при этом довольно дружелюбным. Хм, дружелюбный сосед-питон? (шутка, предоставлена ЗАО «бумер-кринж»).
И о минусах
Что? Секундочку, ведь я только что активно поддерживал Python, а теперь начинаю перечислять минусы? Дело в том, что мне не хочется выглядеть как фанатик в розовых очках. Поэтому я просто назову уже не совсем типовые вещи, но тоже часто встречающиеся:
GIL всё ещё нас беспокоит. В итоге I/O-bound с небольшим количеством CPU-bound может привести к тому, что некоторые сигналы будут не доставлены.
У нас нет оптимизации хвостовой рекурсии (а нужна ли она?). Это большой топик.
Некоторые не любят пробелы… вспомним Whython. Я до сих пор не понимаю, в чем проблема — я везде код форматирую пробелами, а в Python они дают возможность избежать написания «лишних» скобок. Но не признать того, что есть недовольные, нельзя.
Lambda — есть разработчики, которые хотели бы видеть их как функции. Тогда как в Python они устроены в качестве выражений.
Python 2 и 3. Это неактуальный топик на текущий день, и Python 3 принес столько невероятных вещей, что о второй версии говорить нет желания. Но стоит признать — это было больно, и многие ещё помнят, насколько болезненно дался переход. Некоторых это отвращает от языка: подсознательно ты ждешь Python 3 vs 4.
Специфический подход к ООП.
Смешение парадигм даётся не всегда просто.
Я не буду сейчас пытаться разбираться ещё и в этих пунктах, но это всегда повод для отдельной дискуссии. Возможно — в комментариях.
Небольшие итоги
Я хочу сказать, что Python, на мой взгляд, надежен для большинства кейсов, с которыми мы сталкиваемся в бэкенд-разработке. С поправкой на хайлоад, конечно.
Python используется большинством авторитетных компаний, таких как Google и Яндекс. При этом популярность языка продолжает расти, а так же Гвидо недавно на Python Language Summit 2021 обещал, что с поддержкой Microsoft он сделает Python быстрее раз в пять, во многом с помощью jit. Может быть из конца списка языков в бенчмарках мы переместимся в середину, и уж там то точно заживем.
В Python фантастические веб-фреймворки. Можем вспомнить Django или FastAPI — это выдающиеся фреймворки, со своими плюсами и минусами. Современный Python можно брать для написания быстрых, хороших и серьезных бэкендов. В Python-среде много крутых разработчиков и приятных людей!
Python жутко популярен и продолжает расти. Потенциал его роста не исчерпан.
Для меня Python — язык для написания бэкенда номер один. Язык, с которого я начинаю любой бекенд в 2021 и только в каких-то исключительных ситуациях беру другие.
А ещё на Python очень приятно писать код — и этого совершенно не стоит стесняться.
Эта статья — расширенная версия доклада с IT-конференции Райффайзенбанка <code/R>. Здесь много новых подробностей, но если хотите услышать часть голосом — смотрите видео.
Комментарии (83)
hatman
03.12.2021 14:01+9Как человек, который безумно любит питон, могу сказать, что ваш пункт про популярность — манипуляция. Все же не стоит смешивать популярность python для большой кучи сфер (Дата Саенс, Девопс, тестирование, парсеры и так далее) и популярность Python для бекенда (который имеет весьма неоднозначные позиции).
xfenix Автор
03.12.2021 15:08Data science, devops, парсеры — это тоже, во многом, частные случаи бекенда или вещей рядом с ним, я бы так сказал. Конечно, не всё это, но многое применяется в бекендах.
Про неоднозначность позиции в глобальном смысле можно спорить. Я поэтому и написал, что он для меня номер 1.
А у вас есть какой-то язык, который вы считаете доминантным в бекендах?
faiwer
03.12.2021 19:11+4Лучше не мешать эти вещи. И считать backend-ом то на чём пишут серверные решения. Т.е. когда есть сервер, который слушает запросы по сети и даёт свои на них ответы. То что он под капотом использует (почти всегда) базы данных, не делает что же базы данных backend-ом?! А если я числодробилку в WebWorker-е подключу в браузерной вкладке будет ли это frontend-ом? Едва ли. Просто косвенное задействование сопутствующих технологий.
А у вас есть какой-то язык, который вы считаете доминантным в бекендах?
Кажется раньше это был PHP :)
xfenix Автор
06.12.2021 01:00о что он под капотом использует (почти всегда) базы данных, не делает что же базы данных backend-ом?!
А почему нет? БД — часть бекенда. Если ты пишешь свою БД — написанный тобой бекенд.А если я числодробилку в WebWorker-е подключу в браузерной вкладке будет ли это frontend-ом?
Так это фронтенд. Можно сказать, что бекенд фронтенда, если так удобнее. Но код будет крутится на клиенте и формально попадать под определение фронтенд. Даже написан он будет на JS. И заниматься им будут фронтендеры.Едва ли. Просто косвенное задействование сопутствующих технологий.
Вот тут речь о терминологии. Обычно она размытая, но БД расположена на беке, а вебворкер на фронте.
Про бекенд — у нас бекенд на питоне, делает ML предикшены. Чат-бот. Вот он бек, он слушает рэббит, там весь код нами написан. Я считаю его бекендом и это нормально. При том что на клиентов смотрит сервис перед ним. Все эти термины — про разделение проблем. Ну то есть можно назвать это «глубоким бекендом», можно как угодно, но факт в том, что это крутится в наших контейнерах, пишется нами и деплоится тоже нами. Более того, я общаюсь с нашими датасайентистами и мы пишем общие продукты. Для нас проблемы даже общие зачастую.
Если бы мы называли только front-faced сервисы бекендом, то в этом мире не существовало такого явления как tracing, например!
Более того, термины всё таки неточно определены, они про разделение концептов. Вот, например softwareengineering.stackexchange.com/questions/415908/is-the-database-part-of-the-backend целое обсуждение на тему БД — это бекенд или нет. Однозначного ответа нет, хотя многие склоняются к моему видению.Кажется раньше это был PHP :)
О, писал на php 6 лет когда-то.
MentalBlood
03.12.2021 14:06+2достаточно написать пару for и def, объявить несколько переменных — и вот ты уже профессиональный Python-разработчик уровня middle
Смысл понятен, но вообще-то middle на то и middle что умеет разрабатывать сложные вещи, а сложные вещи на то и сложные, что их нельзя описать просто (можно только сложно или еще сложнее))
tmin10
03.12.2021 22:56+1Возможно, что для того, чтобы понять, какие именно переменные объявить, нужно перелопатить кучу внутренней документации и созвать не один митинг, вот уже и задача уровня синиора и выше :) А код, решающий проблему, может быть и простым и сложным, зависит от проблемы и выбранного решения.
Master_Dante
03.12.2021 14:58+3Конечно в статье идет манипуляция статистикой. Популярность среди ботаников и студентов еще ни о чем не говорит. У нас аналитики пишут на питоне... Для статистики важно фактически на чем пишут профессиональные разработчики в реальных производственных задачах.
Второе важен момент производительности. Как вертикальный, так и горизонтальный. Вобщем без сравнения бенчмарков, тут говорить не о чем.
Да кстати откройте nuget и посмотрите сколько там пакетов для веб разработки...
Резюмируя можно сказать Вы очень смелые велосипедисты из Райфайзена. Знаете есть еще С++ и ASM очень клевые языки, тоже не проходите мимо.
xfenix Автор
03.12.2021 15:20+1Я не манипулировал, честно скажу. Поэтому приложил поэтому широкий список разных топов, которые веду не я и не я за них отвечаю. Судить об их объективности я не стал, и написал свои оценочные суждения о самих рейтингах.
У нас тоже аналитики пишут и очень любят язык.
> Второе важен момент производительности
Согласен, поэтому я про это и написал. Асинхронный питон вполне быстрый для I/O нагрузки. Я ориентируюсь в оценках на techempower, как самый известный. FastAPI там звезд с неба не хватает, fastify, fasthttp, tokio — обходят, конечно. Но ведет себя достойно. Доверять ли этому бенчмарку или нет — судить не берусь.
> Вы очень смелые велосипедисты из Райфайзена.
Про нас скажу так: у нас очень интересные люди работают и пишут правда качественный код на Python, велосипеды пишем только в крайней необходимости, т.е. редко.
> Знаете есть еще С++ и ASM очень клевые языки, тоже не проходите мимо
Знаем! Ассемблер — хороший язык (или, скорее, семейство языков), но на нём сложновато писать и не очень нужно в большинстве случаев. Но если понадобилась бы супер производительность в каких-то ситуациях, наверное, им бы могли воспользоваться. Правда, о таком я не слышал.
Про С++ тоже много все вспоминают, язык для индустрии известный и важный. Я так понимаю консенсус наших архитекторов и разработчиков, что мы этот язык не очень поддерживаем тут внутри и от него уходим. Но тут я всей полнотой информации не обладаю, может кто-то из коллег придет и расскажет больше, я скорее просто слышал.
Иногда, в некоторых сценариях, на C++ могут писаться Python модули, но мы у себя тоже не практикуем, хотя банк большой, может кто-то и пишет, за всех говорить не возьмусь.
alec_kalinin
03.12.2021 16:31+7Сдается мне, джентльмены, что в родительском комментарии про C++ и ASM это была ирония.
А если серьезно, то бекэнд бекэнду рознь. Одно дело, если это какая-то типовая финансовая бизнес логика, то тут может быть Python и не самый идеальный выбор. А вот если нужно обрабатывать данные, которые укладываются в численный python с его NumPy + Jax + нейронные сетки, то Python по производительности еще даст фору многим нативным решениям.
Varim
03.12.2021 17:32GIL всё ещё нас беспокоит. В итоге I/O-bound с небольшим количеством CPU-bound может привести к тому, что некоторые сигналы будут не доставлены.
Какие такие сиглалы, что значит не будут доставлены, тоест ьнапример сообщение от RabbitMQ может не доехать до Питона!? Можно подробнее плз.
yakimka8
03.12.2021 18:08Скорее всего автор имел в виду это https://bugs.python.org/issue7946
Вот отличная иллюстрация проблемы https://youtu.be/Obt-vMVdM8s?t=1803
Не уверен что формулировка автора "некоторые сигналы будут не доставлены" верна. IO задачи то будут выполнены, вот только при существовании рядом с ними CPU-bound задач выполнены они будут не так быстро, как могли бы.
sunki
03.12.2021 20:30Правильно понимаю, что решением этой проблемы может быть разделение CPU-bound и IO-bound задач на разные процессы?
xfenix Автор
04.12.2021 02:01Я полагался на вот эту статью https://wiki.python.org/moin/GlobalInterpreterLock, «The GIL can cause I/O-bound threads to be scheduled ahead of CPU-bound threads, and it prevents signals from being delivered» и не очень хорошо перевел/записал, думаю.
http://www.dabeaz.com/python/GIL.pdf для себя я понял, что речь о 18, 23, 25, 26 слайде вот тут. Мне показалось, что говорится конкретно о 25, а остальные больше контекста дают.
Т.е. в целом, ощущение, что это опасность связана с юникс сигналами и кейсом смешения I/O-bound, CPU-bound и все это на тредах/считай с GIL.
Могу ошибаться и/или неправильно понимать.
nullptr
03.12.2021 18:29+6Ждем через пару лет Our journey to type checking 4 million lines of Python Раффайзенбанк-edition.
xfenix Автор
03.12.2021 21:29+1Очень хорошая статья и довольно известная! Спасибо :)
От нас такой именно статьи не будет, потому что мы учитываем чужой опыт и почти 100% кода покрываем аннотациями типов и массово используем mypy. Я очень верю в механизм аннотаций и очень люблю gradual typing.
svok
03.12.2021 18:44+1Если бы вы сделали сравнительный анализ языков, было бы полезно.
А что вы пытаетесь доказать в этой статье - не ясно. Что питон хороший? А кто-то сомневается? И не он один хороший. Полно хороших языков, включая упомянутые здесь уже Assembler, c, c++, java, c#.
Но, чтоб нахваливать какие-то фичи, неплохо бы знать как то же решается в других экосистемах.
xfenix Автор
03.12.2021 21:38+1Если бы вы сделали сравнительный анализ языков, было бы полезно.
Я думаю, у меня знаний не хватит сравнить со многими другими. Не хочется вести как обычно в таких сравнениях случается — поверхностно погружаться в другие языки и так же поверхностно о них судить. Я бы все равно, как разработчик на python, клонил бы в свою сторону, было бы неизбежно. Плюс это бы вызвало негатив у их поклонников и это было бы заслужено.
А что вы пытаетесь доказать в этой статье - не ясно. Что питон хороший? А кто-то сомневается?
Да, хотел сказать, что он хороший, серьезный. Сомневаются, даже тут в комментариях. Очень часто эти вещи, о которых пишу в статье, я слышу. Поэтому и написал статью, наболело.
Полно хороших языков, включая упомянутые здесь уже Assembler, c, c++, java, c#.
Я не хотел «набрасывать» на другие хорошие языки, а хотел рассказать про один, который я хорошо знаю. Поэтому и пишу, что он для конкретно для меня «лучший».
Но, чтоб нахваливать какие-то фичи, неплохо бы знать как то же решается в других экосистемах.
Кое-что про другие экосистемы я знаю, но мне кажется, что не в таком масштабе, чтобы устроить большое сравнение. Идея мне понравилась, спасибо! Я о ней подумаю, может быть правда когда-нибудь найду силы и знания написать такое сравнение.
avengerweb
04.12.2021 05:57Самая большая проблема питона в том что люди лезут писать на нем все что не поподя. Абсолютно забивая на огромное разнообразие других языков и решений. Отсюда выливается миллион проблем, начиная от производительности, когда компания вливает миллионы в AWS, чтобы несчастное приложение работало нормально, заканчивая командами программистов которые тратят огромное кол-во человеко-часов чтобы интегрировать какую-то не очень рациональную для питона фичу. Но зато на питоне.
Как фулстек разработчик, я не вижу никакой вау фичи в питоне, написать не большой скриптец, согласен быстро и удобно на питоне. Написать хоть сколько нибудь сложный бакенд? Боже упаси, это настолько неудобно что хочется плакать, особенно когда песня начинается про поддержку кодовой базы. Конечно основной причиной плохого кода всегда являются программисты, а питон всего лишь инструмент, очень добродушный…
KoteMilote
03.12.2021 18:55+2Придёт время и Kotlin отожмёт часть ниши у Питона, вопрос только - на сколько большую
faiwer
03.12.2021 19:03+3Какой-нибудь JSON-парсер на языке со статической типизацией будет гораздо более многословным и тяжелым в написании, чем на языке с динамической типизацией
Под JSON-parser-ом вы имели виду валидатор? Если да, то не сказал бы. В TypeScript с IO-TS вы можете весьма тривиально типизировать и провалидировать JSON одним и тем же кодом. Выглядит примерно так:
const IO_User = strict({ id: number, username: string, birthday: orEmpty(IO_Date) }); // ... const user = validate(JSON.parse(json), IO_User); /* typeof user === { id: number, username: string; birthday: Date | null; } */Заметьте, одновременно ещё и
stringвDateсконвертировали. IO-TS умеет и в очень сложные типы, и в алгебру типов.Или всё же речь шла про настоящий парсер произвольного JSON? Такое точно удобнее писать на статически типизированных языках, т.к. на них удобнее писать сложные конечные автоматы. Не приходится всю картинку держать в голове и отлаживать глупые кейсы, когда сам что-то забыл.
Где-то, где мы в Python отобьемся манипуляциями в рантайме, придется подтаскивать большие объёмы кодогенерации.
Сейчас появились языки, с которыми многие фишки из динамических языков… внезапно можно типизировать и без кодогенерации. Typescript тому пример. Обычно ценой там выступает сложность описания соответствующих типов. Но 95% он покрывает.
KoteMilote
03.12.2021 19:23На хабре писали:
Instagram написан на Python и Django. Хоть у Python и есть проблемы с CPU-intensive задачами, но зачастую, в веб приложениях, ориентированных на контент, основная нагрузка это - I/O intensive задачи. К тому же, большая часть проблем, решается за счет уровней кеша, CDN и тд.
ЗЫ: основная часть DropBox также на Python, но на 2-й версии. И сам Гвидо долгое время работал на них.
https://habr.com/ru/company/otus/blog/591983/#comment_23779785
То есть у Питона есть своя ниша в вэб приложениях, она обозначена выше, но приложения с разветвленной бизнес логикой - это не к нему.
tropico
04.12.2021 02:02+2но приложения с разветвленной бизнес логикой - это не к нему
Не так давно половина (если не больше) Cisco на бэкенде была написана на пайтоне с сотнями сервисов на самописных фреймворках с тредингом и мультипроцессингом на десятках продуктов, которые приносили и приносят миллиарды в год.
KoteMilote
04.12.2021 09:31+1Так как так то, объясните джуну Java) как можно писать бэк, если нельзя после объекта поставить точку и увидеть всё методы которыми я могу воспользоваться? Или как можно не накосячить не зная какой тип переменной в конкретном участке кода?
Если как писали на Хабре: все решается аннотациями, которые из динамической типизации превращают Пайтон в статическую, то в чем тогда вообще его фишка? В синтаксическом сахаре? Так можно написать библиотеки и юзать их где надо.
Я просто не понимаю как пишут большие проекты на Питоне, почему это выгодно? Потому что всё положительные моменты от Питона действуют только на старте проекта (как я понял)
tropico
04.12.2021 22:09как можно писать бэк, если нельзя после объекта поставить точку и увидеть всё методы которыми я могу воспользоваться?
Это как нельзя? Наверное только если писать код в блокноте.
Или как можно не накосячить не зная какой тип переменной в конкретном участке кода?
Если у кого-то не хватило ума поставить ретурн-тайп в докстринге метода (до появления аннотаций в 99% случаев никто бы не пропустил без него на код-ревью), тип можно понять или в дебаггере или по названию или как эта переменная используется в других частях кода. Никогда не сталкивался и не слышал о таких проблемах ни на втором, ни на третьем пайтоне.
то в чем тогда вообще его фишка
Как минимум нет сишных скобочек, которые являются визуальным мусором
KoteMilote
04.12.2021 23:25Уверен дело не только в скобках.
На мой взгляд ретурн-тайп и аннотации выглядят как костыли которые ломают принципы языка.
Мой вопрос был связан с этой статьей, где автор писал про типизацию следующее:
Да, в 3-й версии Питона появились средства явного указания типов, т.е. авторы языка сделали большой шаг в сторону статической типизации, но на текущий момент эти новые фичи слабо поддерживаются как сообществом, так и интерпретатор довольно лоялен к нарушению типизации (по сравнению со строгими языками).
Вторая проблема динамической типизации - это подсказки IDE. Если явно не задан тип объекта, то и отследить его текущий тип очень часто невозможно. Раз тип неизвестен, то и подсказать доступные методы для переменной тоже невозможно. В таком случае, IDE уже не работает как помощник разработчика, а просто служит текстовым редактором.
Далеко не всегда динамическая типизация создает какие-то проблемы. Если программа небольшая и разработчик способен отследить все изменения типов, то работать с динамическими типами гораздо проще, чем явно описывать все классы и типы.
Но, если ваша программа разрастается до больших размеров, то тут уже IDE часто сдается, перестает помогать и уходит много времени на выяснение типов и доступных методов. Также возникают постоянные проблемы с типами, которые никак не отследить и можно выявить только с помощью модульного тестирования. Модульное тестирование - это нужная и полезная вещь, но динамическая типизация предъявляет повышенные требования к нему и требует большего покрытия тестами кода. И чем больше проект, тем будут больше издержки на отладку и поддержку.
Получается это не так?
TimurBaldin
05.12.2021 01:42Ну это всего лишь подсказки по типу , это если и шаг в сторону типизации то очень маленький и незначительный)
В целом это костыль, мое личное убеждение , что должна быть статическая типизация и опционально динамическая,но не наоборот )
xfenix Автор
05.12.2021 20:36+1Да, в 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 типизация — здоровый компромисс между статической типизацией и динамической. Можно быстро, понятно, надежно и не надо выбирать из трёх, можно все три.
Никто не отменял языки со статической типизацией, никто не говорит, что они плохие. Просто питон действительно по совокупности факторов тоже теперь сильный игрок, вот о чём я и говорю, о чём и написал статью.
TimurBaldin
05.12.2021 01:36+1Нет, иногда действительно показываются методы которые в реальности не существуют у объекта , сам с таким сталкивался при работе с внешней библиотекой )
Ага, особенно прикольно когда стоит Any или подсказки по типу нет из-за старой версии библиотеки ) Непонятно зачем нужны такие костыли, если есть нормальная статическая типизация и опциональная динамическая (в C# она неплохо реализована)
0xd34df00d
03.12.2021 22:39+4Тоже зашёл в комментарии поговорить о жсоне и статически типизированных языках.
Если у меня есть какая-то структура, то я просто объявляю соответствующие типы, где-то рядом указав конкретные настройки жсон-парсера. Всё, всё остальное за меня делает компилятор и библиотека. При этом никакой кодогенерации, дополнительных файлов не появляется, всё — в кишках компилятора в компилтайме.
А если структуры нет, то я просто использую библиотечный ADT, и всё. И мне даже в него лезть не надо, потому что у меня же нет структуры, откуда я знаю, куда лезть?
xfenix Автор
04.12.2021 02:23TypeScript мне очень нравится, сам пишу фронтенд на нём, можно сказать, мой второй язык. Считаю связку python + annotations + mypy + typescript — очень рабочей.
Но в его системе типов я пока не очень силен, честно говоря, type challenge пока не шибко хорошо идет.
Про валидацию: у нас все схемы написаны на zod, он мне больше почему-то понравился. Наверное, я его в начале потащил из-за safeParse, я прям очень-очень не люблю try-catch в js, а в ts меня от него совсем плохо.
McKinseyBA
03.12.2021 19:37+5Зашел прочесть, что такого крутого Райф сделал в бэкенде на Python... и не увидел. Плохо смотрел, ткните пожалуйста? Кликбейтный заголовок, по моему скромному ИМХО, нужно делом подтверждать, рассказывая, что на Python написано в бэке.
При этом язык и правда отличный - кто бы и что не говорил, особенно для всевозможной автоматизации, а также подготовки и анализа данных. Сам осенью чуть-чуть к нему прикоснулся в рамках научной статьи для примитивного анализа данных.
Глобальный же вопрос "Какой язык лучше для <x> ?", имхо, не имеет смысла. Какая разница на чем писать, если задача решена и "бизнес счастлив"? Да хоть на brainfuck.
Также предлагаю не париться на тему о "серьезности/несерьезности" языка в чьих бы то ни было глазах - какое Вам дело до чужого мнения, если вам нравиться Ваш любимый инструмент и Вы умеете с его помощью давать бизнесу ценность, отраженную в вашей зарплате? Немного из другой оперы, но мне нравиться статья английской википедии о полноте по Тьюрингу языков программирования - там даже Minecraft и Excel упомянуты как "непреднамеренно полные по Тьюрингу" :-)
sunki
03.12.2021 20:15+2"Какой язык лучше" может и не имеет смысла, если задача уже решена. А если еще нет, то очень даже имеет) Есть какой-то набор объективных метрик, позволяющий сравнивать одно с другим. Например, тот же GIL или динамическая типизация в одном случае норм (и даже плюс!), а в другом не очень норм. Для веба такая типизация ок, потому что можно быстро чинить баги, выкатывать новый код. Для десктопов – сомнительно, накатить новую версию сразу всем клиентам может быть не просто.
xfenix Автор
03.12.2021 22:08+1Зашел прочесть, что такого крутого Райф сделал в бэкенде на Python... и не увидел. Плохо смотрел, ткните пожалуйста? Кликбейтный заголовок, по моему скромному ИМХО, нужно делом подтверждать, рассказывая, что на Python написано в бэке.
Ну не такой он уж кликбейтный, ведь Python — серьезный язык! Ну, разве чуть-чуть, простите уж за такую шалость :)
Так уж вышло, вот эту статью мне удалось доредактировать чуть раньше. Сейчас я пишу о сообществе и начал писать о нем раньше этой статьи. И та статья должна была выйти раньше, став первой. А вышла эта, поэтому она немного вырвалась вперед, создав вот это громкое (я хотел бы верить) впечатление.
Про подтверждать делом — всецело разделяю, мы будем стараться, не всегда просто рассказывать про внутренние продукты.
https://habr.com/ru/company/raiffeisenbank/news/t/586976/ мы немного рассказывали вот тут с командой и https://habr.com/ru/company/raiffeisenbank/blog/552734/ вот тут (но там про Python довольно мало). На code/r https://habr.com/ru/company/raiffeisenbank/blog/586042/ вот тут я выступал с докладом, который и лег в основу статьи.
https://habr.com/ru/company/raiffeisenbank/news/t/566370/ вот тут у нас был открытый митап (есть на ютубе).
Вот тут мы выступаем на конференциях:
https://www.youtube.com/watch?v=4zjj1aHJoko
https://www.youtube.com/watch?v=_nl1e4TWQ0Q
https://conf.python.ru/moscow/2021/abstracts/7746 (тут рассказываем о нашем сервисе вебсокетов, это чисто бекенд, python, zeromq, k8s — я надеюсь, что у нас там довольно интересный доклад получился, т.к. сам сервис я считаю очень любопытным и довольно технологичным; видео пока не вышло, но есть презентация).
Про решение больше расскажу. Мы с командой (не community — в нем куда больше людей) пишем чат-систему, довольно большую, на Python и TypeScript, а так же чат-бота на Python (там тоже очень много всего). Весь бекенд продуктов — 100% Python, мы используем k8s, микросервисную архитектуру, покрываем все аннотациями, активно используем pytest, hypothesis, mypy, pylint, sonar, у нас автоматизированный code-style (про него статью я тоже пишу) и много чего ещё.
Так же у нас есть ещё несколько команд (community), делающих разные продукты, но я не знаю могу ли я про них говорить. Может быть их участники смогут что-то рассказать, если у них есть аккаунты, я спрошу. Мы постараемся больше рассказывать в будущем о python решениях в банке.
Также предлагаю не париться на тему о "серьезности/несерьезности" языка в чьих бы то ни было глазах - какое Вам дело до чужого мнения, если вам нравиться Ваш любимый инструмент и Вы умеете с его помощью давать бизнесу ценность, отраженную в вашей зарплате?
Спасибо! В целом, понимаю и отчасти принимаю эту философскую позицию и даже считаю её очень умной. Но я решил высказаться, потому что наболело. Плюс, я работаю с сообществом, общаюсь с множеством разных людей, команд, бизнесом и довольно часто в дискуссиях при выборе языка мы чувствуем стигму «не очень серьезного языка». Для меня, словом, это важный вопрос, я не лукавлю. Если бы это касалось меня одного, я бы никогда не решился написать такую статью и высказаться по этой теме, ибо просто бы следовал вашему совету.
Немного из другой оперы, но мне нравиться статья английской википедии о полноте по Тьюрингу языков программирования - там даже Minecraft и Excel упомянуты как "непреднамеренно полные по Тьюрингу" :-)
Занимательнная ссылка, спасибо! :)
iShrimp
03.12.2021 22:06+1Когда обсуждают скорость Python, обычно вспоминают про C++, ведь на нем все бенчмарки выглядят в сто раз лучше, чем на Python. Но если мы начнём разбираться в вопросе, то станет ясно, что скорость Python на данном этапе — не такая уж проблема. Конечно, Python действительно медленный в CPU-bound задачах.
Сколько лет существует Python, столько же лет его ругают за производительность. Конечно, есть такие решения, как pypy, numba, но если Python претендует на роль универсального языка, то почему нельзя сделать дефолтный оптимизирующий JIT, как в Java или C#?
xfenix Автор
03.12.2021 22:22+2Отличная мысль!
По-моему, дело обстояло так. Гвидо долго говорил, что хотите быстрый python — возьмите pypy, в котором jit и который действительно дает значительное ускорение.
Но в прошлом году Гвидо надоело быть, так сказать, на отдыхе и Microsoft выделил денег и поэтому случилось невероятное — https://mail.python.org/archives/list/python-dev@python.org/message/WVURDCWRH7F5UDLU5ZLT5P35ZO6TIBYA/
https://www.python.org/dev/peps/pep-0659/
https://github.com/faster-cpython/ideas
https://github.com/markshannon/faster-cpython/blob/master/plan.md — тут есть план, что python 3.12 принесет нам jit!
Мы очень сдержанно сидим и радуемся этим выдающимся новостям :)
emaxx
03.12.2021 23:15Можно ли в двух словах объяснить, в чём отличие от PyPy (и, если оба будет jit, то зачем их два)?
xfenix Автор
04.12.2021 02:11+1Мне кажется, что никто не знает пока, т.к. это только декларация о намерениях.
В теории можно полагаться на это: 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 — вопрос, конечно.
yokotoka
03.12.2021 22:11+13Для меня Python хорош тем, что автор языка ОЧЕНЬ сильно заморочился чтобы сделать язык для людей (и не с первого раза получилось и не то что бы "получилось", но всё же). Причём, для настоящих людей, а не вымышленных - ну, знаете, тех, которые в каждую минуту своей жизни знают наизусть и помнят все тонкости C++ и не допускают ошибок в коде и утечек памяти, с удовольствием пишут километры лишних, ненужных слов на Java, помогая транслятору, который сам не догадается, мгновенно парсят глазами и мозгом винегрет из слов со спецсимволами в Rust, радуются что JavaScript сам по себе очень компактен, практически ничего не умеет и всё решается гигабайтами библиотек в npm, так завязанных друг на друга так, что в этом мире зависимостей всегда что-то сломано и т.п.
Язык без лишнего визуального мусора. С кучей возможностей. С терпимыми недостатками. Да, он не идеален. Но когда пытаюсь использовать что-то другое, всё время ловлю себя на мысли "ну как же так можно было упороться и принять такие идиотские решения в дизайне языка, что простую, казалось бы вещь, приходится делать с печалью на лице". При том, что Python - это не моя мама-утка, начинал я вообще с Pascal/Delphi/Basic и лет 6 сидел на PHP.
Flux
04.12.2021 00:59+5автор языка ОЧЕНЬ сильно заморочился чтобы сделать язык для людей
И это одновременно благословение и проклятие для пишущих на нём. Python это действительно язык для людей, но проблема в том что выбрав его за эту черту можно однажды обнаружить себя в ситуации когда тебе нужен язык для программистов, а ты выбрал язык для людей.
Он замечателен когда нужно писать небольшие приложения для которых не нужен сложный computing за пределами подключаемых библиотек. Я пару раз оказывался в ситуации когда проект начали писать на питоне и около года хорошо обходились возможностями numpy, а потом появлялась необходимость справляться с в 10-100 раз большей вычислительной нагрузкой. И начинался ад, потому что человеческой многопоточности в языке нет, мультипроцессинг до 3.8 удваивал потребление памяти, и еще много, много неприятных вещей. Код на плюсах который решал задачу в 3-10 раз быстрее и мог сожрать в 2-3 раза больший инпут писался в 2-3 раза быстрее чем его аналог на питоне.
И вся эта боль от того что при старте проекта кто-то смог быстренько набросать mvp на фласке и показать менеджменту.
Python хорош, но далеко не для всего бекенда. И у меня наверное никогда не перестанет гореть от того что именно он захватим ML и DS сферу.
0xd34df00d
04.12.2021 03:41+2Python хорош, но далеко не для всего бекенда. И у меня наверное никогда не перестанет гореть от того что именно он захватим ML и DS сферу.
Я наполовину из-за этого перестал заниматься DS, и гореть тоже перестало!
TimurBaldin
05.12.2021 01:49Вот согласен !
В ML и DS прекрасно могли себя чувствовать C# и Java )Но, к сожалению эти языки не так добры к новичкам)
Alexey2005
04.12.2021 00:33+4Основная киллер-фича Python, из-за которой он так легко проник в академические круги и прочно обосновался в Data Science/Machine Learning — его сверхвысокая толерантность к техническому долгу.
Проще говоря, когда на говнокод, написанный на любом другом языке, уже и дышать страшно, не то что менять, поверх Python-говнокода просто набрасывается очередной костыль и всё успешно работает, даже не думая коллапсировать.
Загляните в любой проект, связанный с нейронками — там везде под капотом такая жесть, что волосы встают дыбом на всех частях тела. И, конечно же, никаких тестов, практически никогда ничего похожего на вменяемую документацию, всё собрано из говна и палок, смотанных синей изолентой. Это типичный академический код, и ничего кроме Python такое не вывезет.
Мало того, Python позволяет этот говнокод не только написать и забыть, но ещё и реиспользовать. И просто собрав вот такие поделки со всего Интернета, слепить их вместе, причём очень быстро, и это даже будет работать.Flux
04.12.2021 01:01+1Загляните в любой проект, связанный с нейронками
Зачем вы так, у меня снова Вьетнамские флешбеки начались.
karomag
04.12.2021 01:45+1Я думал только 1Сники считают себя неполноценными)))
xfenix Автор
05.12.2021 03:15Это моя рефлексия, не хотел бы создать неверное впечатление о питонистах. Я вижу, что язык в дискуссиях любят приложить, поэтому высказался, это мое видение проблемы. Могу ошибаться.
Большинство из питонистов, насколько мне известно, не испытывают проблем и не чувствуют себя ущемленными. И правильно, язык то замечательный (кто о чём, а я всё о том же) :)
huaw
04.12.2021 11:10-1Питон - лучший!
За 20 лет перепробовал все языки, которые только возможно, начиная с Асма и Бейсика, через Си, Паскаль, Пхп, Яву, Яваскрипт и до Раста.
И хочу сказать, что нет ничего более человечного и молниеносного для разработки, чем Питон. Особенно после внедрения typing. Максимальная человекочитаемость и выразительность, нет такого ни у одного другого мэйнстримного языка.
Осталось дать каким-либо образом ему работать в браузере (встроенная ли это будет виртуальная машина или компиляция в wasm), и Питон захватит веб полностью, а недоразумение по имени Яваскрипт отправится туда, откуда приползло :)
ОС и драйвера, конечно, на нём не напишешь, но он и не об этом, это идеальный язык именно для высокого уровня.
justPersonage
04.12.2021 11:27+2Питон — лучший!
За 20 лет перепробовал все языки, которые только возможно, начиная с Асма и Бейсика, через Си, Паскаль, Пхп, Яву, Яваскрипт и до Раста.
А чем ява хуже питона? (кроме многословности)TimurBaldin
05.12.2021 01:24+1Да … ничем не хуже) Есть случаи когда полезна динамическая типизация (например для прототипов, devOps, аналитики )
Мне забавно читать про «многословность» …прям представляю разработчика который сидит и считает слова и буквы в коде)))
AlexPoz
04.12.2021 11:27+1Похоже травля достигает предела.
Я вообще дотнетчик и порой тоже шучу о питухоне или пыхе, но это совсем не означает, что эти языки не подходят для интерпрайса.
Мне кажется основная проблема питона в большом количестве школ, которые за три дня из школьника сделают мидл говнокодера. Потом эти говнокодеры накатают тонны так себе кода и питона ждёт наследство от пыхи.
Если есть ребята, которые пишут бэк на жабаскрипте, то питон отличный язык для бэка. Я как-то переписывался бэк... Плакал... Долго плакал. Ребята, если вы отличные спецы в фрон, не ходите в бэк плиз, мы же не ходим к вам в фронт и вы не ходите к нам.
xfenix Автор
05.12.2021 03:10Да травли то особой нет, питон почти все любят. Но имидж не самый лучший сложился. Поэтому я люблю транслировать свою обратную позицию и на этой теме ловить тухлые помидоры.
Отчасти со школами, кажется, так. Но я вот что думаю: неофиты всегда несут проблемы, но это и благо тоже. Да, конечно, на имидже языка сказывается, но зато есть приток новых способных людей, которые рано или поздно создадут что-то стоящее. В конечном счёте, это хорошо, что школ много.
Про специалистов back-front не поддержу, т.к. я за дружбу фронтов и беков, я сам фуллстек, начинал в 2005 году с верстки сайтов, поэтому для меня бек и фронт — не два разных человека, а голоса у меня в голове :)
TimurBaldin
04.12.2021 15:39+1Имел опыт разработки на python после java .
Для быстрого создания прототипов или небольших приложений хороший инструмент , но динамическая типизация в большинстве случаев это зло. Аргумент «динамическая типизация» позволяет писать меньше кода — правда,но лишь отчасти, разницу в размере кода будет компенсировано большим количеством тестов.
Это единственный (на мой взгляд), но очень серьезный недостаток, который не позволяет python конкурировать с java или C#
P.S
Забавно, я не встречал статей «Java — серьезный язык …» или «C# — серьезный язык …»
xfenix Автор
05.12.2021 03:13Понимаю.
Я как раз в статье пишу про аннотации типов, они снижают накал этой проблемы. Они завозят gradual typing в python, у нас даже алгебраические типы есть. Ну и дженерики всякие, файналы. Type guards, type narrowing появился вот в mypy. Проблема уже решаемая, инфраструктура питона прокачалась. Там не всё ещё идеально (вспоминаю stubs, typeshed, type-*), но очень неплохо сейчас.
Мы покрываем ими весь код и рекомендуем всем людям в community делать так же.
TimurBaldin
05.12.2021 12:46Да, но это лишь «подсказки типов данных», мне бы конечно хотелось бы, чтобы статическая типизация была по умолчанию, а динамическая опциональная (как в C# )
xfenix Автор
05.12.2021 13:43Довольно часто звучит эта самая обесценивающая формулировка — «всего-лишь аннотации».
Но что это значит? Да, у нас нет прям полноценного «вывода типов» (термин, который связан со статической типизацией, насколько я понимаю), но mypy делает очень неплохой статический анализ и типы всё таки анализирует. В итоге сказать, например, что статический анализ аннотаций значительно уступает настоящей статической типизации — было бы не очень корректно.
А ещё исследования статической типизации часто предвзяты и некорректны, когда клонят все в преимущества статической типизации над динамической.
Т.е. получается и нет четких доказательств, что статическая типизация доминирует как и нет доказательств, что аннотации ей чем-то уступают. Так что я бы не стал их обесценивать, т.к. нет доказательств того, что они хоть чем-то плохи.
Мое субъективное мнение такое: Gradual typing — лучшее от обоих миров. Я считаю, что Python и TypeScript пошли по правильному пути, избрав эту концепцию.
Ключевое преимущество языков с динамической типизацией — скорость разработки. Мы просто быстро пишем код, а аннотации стоят рядом и позволяют сделать из этого кода — очень надежный код. Это именно то, что идеально вписывается в agile мир.
Python за аннотации можно было бы накинуть в другом направлении — mypy все ещё не идеальный инструмент.
TimurBaldin
05.12.2021 14:53В итоге сказать, например, что статический анализ аннотаций значительно уступает настоящей статической типизации — было бы не очень корректно.
Уступает, так как даже самые древние библиотеки будут использовать статическую типизацию . Например в Java , возьмите любую библиотеку и вы точно будете знать, что вам возвращается и как с этим объектом работать . Основное преимущество статической типизации это четкий контракт взаимодействия для любой версии языка .
Ключевое преимущество языков с динамической типизацией — скорость разработки.
В целом да, на себе ощутил, что накидать прототип быстрее . Но, если выйти за пределы прототипирования, то скорость разработки (учитывая классные, современные framework-и) будет сравнима (для Java это Spring ). В целом python классный инструмент, у нас он очень активно используется для инфраструктуры, но весь бэк на java был есть и будет)Чему я очень рад)
P.S
Вполне возможно, что я не прав и просто хочу из python сделать java ))xfenix Автор
05.12.2021 15:18Уступает, так как даже самые древние библиотеки будут использовать статическую типизацию . Например в Java , возьмите любую библиотеку и вы точно будете знать, что вам возвращается и как с этим объектом работать . Основное преимущество статической типизации это четкий контракт взаимодействия для любой версии языка .
Поэтому я и написал — «значительно».
Кроме того, у питона есть ответ на это — .pyi и py.typed, typeshed, теперь types-*
Пока это работает не идеально. В TypeScript тот же types сильно круче, даже у самых мелких пакетов нередко есть *.d.ts.
Вполне возможно, что я не прав и просто хочу из python сделать java ))
Да у языков много общего. Сейчас у питона появился статический анализ, питон компилируется в байт код и исполняется на виртуальной машине...
TimurBaldin
05.12.2021 15:34Пока это работает не идеально.
Ну вот да, с точки зрения бизнеса я бы не выбирал инструмент где такая важная часть как типа данных "значительно уступает"
Даже у вас в банке, как много сервисов написанных не на python ?xfenix Автор
06.12.2021 00:41Не совсем такая была моя цитата.
В итоге сказать, например, что статический анализ аннотаций значительно уступает настоящей статической типизации — было бы не очень корректно.
Моя цитата была такой, пожалуйста, не вырывайте из неё кусок в свою пользу. Значительно не уступает. Он работает в той степени, что хватает бизнесу. У нас очень мало ошибок в рантайме, а связанных с типам около ноля. И у языков со статической типизацией ошибки в рантайме тоже бывают, есть про это и исследования.Ну вот да, с точки зрения бизнеса я бы не выбирал инструмент где такая важная часть
Несмотря на некорректную цитату, скажу про это: если бы бизнес выбирал только идеальные инструменты, бизнес бы не выбирал ничего, т.к. таких инструментов нет. Выбор бизнеса не про технологии и не про надежность, а скорее про рынок, популярность и наличие специалистов. И с последним абсолютно у всех сейчас проблемы (большой дефицит всех).Даже у вас в банке, как много сервисов написанных не на python ?
Я возможно создал неправильное впечатление и прошу за это прощения!
Я не хотел сказать, что у нас ВЕСЬ банк на python пишут, или что он у нас главный язык, возможно я создал несколько неправильный посыл.
Питонистов у нас относительно джавистов, мало, как и в любом банке. Конечно же у нас огромная кодовая база на джаве и никто её никуда не девает и от неё не отказывается. Джава здорова, бодра, весела и много крутых джавистов.
А я развиваю питон сообщество, не так давно, буквально второй год и рассказываю почему питон хорош, в том числе, как альтернативный стек внутри, а теперь и снаружи банка. Питонистов у нас в банке много, но далеко не все из них бекендеры.TimurBaldin
06.12.2021 01:55+1Цитата была действительно неверная, прошу прощения !
Надеюсь python будет расти и здравствовать и составлять достойную конкуренцию Java и C# , как не крути единственный путь развития это конкуренция )
Спасибо за статью и за доп.информацию о типизации)
P.S
Возможно Graal VM даст хороший толчок для развития python в корпоративном сегменте )
xfenix Автор
06.12.2021 03:00Надеюсь python будет расти и здравствовать и составлять достойную конкуренцию Java и C# , как не крути единственный путь развития это конкуренция )
Согласен. Спасибо!
Graal VM — интереснейший проект!
0xd34df00d
06.12.2021 02:41+1И у языков со статической типизацией ошибки в рантайме тоже бывают, есть про это и исследования.
К этим исследованиям (особенно тому самому про проекты на гитхабе) есть методологические вопросы. Вот два сходу:
- Как учитывается сложность проектов? На JS или питоне пишется сильно меньше компиляторов, чем на условном хаскеле.
- Как учитываются те проекты, которые не выжили? Звучит разумным предположение о некотором пороговом значении, после которого проект тихо подыхает, возможно, не дойдя до гитхаба. Тогда более-менее равное распределение багов по всем языкам будет как раз ожидаемым.
Обратно, есть и такое исследование — там брали проекты на JS, выбирали коммиты, чинящие баги, добавляли аннотации типов в окрестности бажного кода, и смотрели, сколько багов поймается (поймалось 15%). Проблем с методологией меньше — это заведомо один язык (JS с навёрнутым поверх TS или Flow), одни проекты (разница в сложности до фикса и после фикса пренебрежимо мала), и явно прошедшие через тесты и какое-то использование автором до коммита баги.
И по ряду причин 15% — это сильно консервативная оценка.
xfenix Автор
06.12.2021 02:59К этим исследованиям (особенно тому самому про проекты на гитхабе) есть методологические вопросы
Как и ко многим другим, доказывающим преимущество статической типизации https://danluu.com/empirical-pl/. Тут я все таки еще опираюсь и на Uncle Bob и на некоторых других. Конечно, тут можно мне впаять аппеляцию к авторитетам, но т.к. поле информации огромно, а на миллион проектов посмотреть я не могу и не смогу, мало что остаётся. В основном, я тут топлю за python, не против других языков :)
Обратно, есть и такое исследование — там брали проекты на JS, выбирали коммиты, чинящие баги, добавляли аннотации типов в окрестности бажного кода, и смотрели, сколько багов поймается (поймалось 15%).
Надо почитать, тут так то просто выводы сходу не сделаешь. Информация как минимум любопытная, спасибо.
Тогда более-менее равное распределение багов по всем языкам будет как раз ожидаемым
Вероятно, ну у нас тут довольно эмпирическое поле, конечно. Исследований, надежных, исчезающе мало, поэтому я предпочитаю не считать, например, что аннотации — припарка от всего, такого точно нет. Я считаю, что они повышают надежность и даже по исследованию выше — это так и есть. Но и без исследований, чисто эмпирически, и я и многие коллеги находим с ними проблемы и почти никогда я не встречаю в наших проектах type error'ы. На нашем коде — точно нет.
0xd34df00d
06.12.2021 03:30+1Тут я все таки еще опираюсь и на Uncle Bob и на некоторых других.
Дядя Боб — это, конечно, специалист, но специалист в ООП и прочих аджайлах, а не в типизации. Я с некоторыми его мнениями на тему тоже знаком, но у меня сложилось впечатление, что он свои выводы делает на основе знакомства с джавой. Впрочем, его можно понять — на основе знакомства с джавой я бы делал похожие выводы.
Но и без исследований, чисто эмпирически, и я и многие коллеги находим с ними проблемы и почти никогда я не встречаю в наших проектах type error'ы. На нашем коде — точно нет.
Ну если говорить об эмпирике и личном опыте — на голом питоне (или жс, или любом другом языке) без типов я писать не могу, моя производительность как функция от объёма уже написанного кода падает экспоненциально и в районе 50-100 строк становится неотличима от нуля. mypy ради интереса потыкал пару лет назад, и, конечно, это шаг вперёд, но выразительная сила типов не отличалась существенно от плюсовой, да и куча библиотек была неаннотирована.
Ну и я не понял, зачем оно такое надо, если новые проекты можно писать сразу на языках, более дружественных к выразительной типизации и при этом не требующих кучу ритуалов, ассоциирующихся с типизацией у среднего джависта. Но это стандартная проблема с прикручиванием к уже существующему и более-менее устоявшемуся языку фич, которые не были учтены при его проектировании.
titan_pc
04.12.2021 15:40+4Чтобы ответить себе на вопрос "чем твой любимый язык лучше другого". Ну например, чем питон лучше java?
Надо взять двух мидлов. И дать мидлу java покидать камни в питон. Ну тоесть выслушать а чем же язык плох?
Потом обоим поставить одну и туже задачу. Ну например, сделать миркросервис, который читает/пишет данные в постгрес из 3х справочников. Создать, обновить, удалить, чтобы всё там работало. Завернули чтобы в докер и закинули в кубер. Ограничение 10 под.
Важнон условие, чтобы роуты одинаково работали и назывались.
А потом тестируем нагрузку на сервисы не питоном, а продуктом на джаве jmeter. Ну число одновременных пользователей, время отклика и прочие радости. Прогоните 10 тестов одинаковых
После тестов, вы - как минимум перестанете сравнивать языки и успакоитесь. Кто кидался камнями - перестанет. И наступит мир)
Потому что, окажется что в 4х тестах выиграет питон, в 4х java. А в двух последних упадёт кубер, ибо ингресс контроллер тоже оптимизировать надо. И разница в победе там не в разы, десятки киллограм, а на одну дольку апельсина.
Потом ещё с++ ника надите. С# писта. И всех недовольных кто кидает кирпичи.
Бенчмарки от институов забугорья это конечно прикольно, но реалии таковы, что для выкручивания языка на такие бенчмарки скилов днём с фонарём не сыщешь. И в итоге все на средних скоростях и работают. В коробку вам никто в опен сорс либы не заложил супер производительность. И в язык тоже не прикрутил в коробку. И вообще никому мы там не нужны, чтобы секреты супер быстрого кунфу нам раскрывать.
Все языки так или иначе потом в железо упираются и операционку. И кубер куберу кубернет. У кого на центосе, у кого на убунте.
Ну а на питоне кодить - удовольствие)
KoteMilote
05.12.2021 10:05В коробку вам никто в опен сорс либы не заложил супер производительность. И в язык тоже не прикрутил в коробку. И вообще никому мы там не нужны, чтобы секреты супер быстрого кунфу нам раскрывать.
То есть, за бугром Java работает быстрее чем тут????
DimaVadovov
Читать интересно, понятно, что язык Вам нравится, но не понял, о какой иронии говорили в начале
xfenix Автор
Спасибо! А тут так вышло — текст писался как пересказ доклада на конференции и там, в видео, ирония была. При переносе в текст, казалось, что она останется, но куда-то в итоге испарилась. Этот кусок текста явно из прошлого. Так сказать, баг в продакшене :)