Мы в Evrone часто сталкиваемся с легендой, что для задачи, которая встает перед программистами, есть какой-то волшебный, лучший инструмент. К примеру, если вы хотите сделать что-нибудь бэкендовое, вам обязательно нужен PHP. А если вы хотите создать крутой современный фронтенд, то без JavaScript вам делать нечего. Если же вы такой хипстер, что хотите быстро делать фулстек фичи, то вам просто необходим Ruby. И, наконец, если у вас ML, artificial intelligence, big data или просто вам на бэкенде нужен какой-то клей, чтобы работать с данными, то вам жизненно необходим Python.
Python самый популярный язык программирования в мире
Начнем с того, что произошло 40 лет назад, когда Гвидо ван Россум только закончил учиться на профессионального автора языков программирования (!), и на фултайм работе делал язык программирования ABC. В 1986 году Гвидо завершил работу над ним, и вместе с тем самым Таненбаумом, который написал толстую книжку, начал делать операционную систему Amoeba. Гвидо надо было делать для неё скрипты, и он как профессиональный разработчик языков программирования, начал делать новый язык для себя. Чтобы создавать скрипты как клей для доступа к к системным библиотекам, написанным на С.
У команды, которая работала над Амебой, была добрая традиция называть программы для этой операционной системы в честь телешоу. Так что язык Python не просто так называется в честь телешоу «Монти Пайтон».
В 2000 году Гвидо присоединился к команде Zope, которая делала пайтоновские фреймворк, инфраструктуру и т.д.. Это можно считать стартом мировой популярности Python.
Python лучший язык для обучения
Ноги Python растут из языка ABC, который пытались сделать для обучения новичков. Но это было 40 лет назад, с первого раза у Гвидо не получилось, зато неплохо получилось со второго.
Когда Python был создан, его разработчики написали Zen of Python — манифест из 10 пунктов, который подчеркивал основные ценности языка. Например, что «simple is better than complex, but complex is better than complicated», разумные принципы программирования. Python считается очень хорошим языком для обучения, лучшим, чем JavaScript, потому что он придерживается принципа «минимального удивления». Новые разработчики минимально удивляются поведению кода, который они написали. Python логичен, предсказуем и большинство штук в нем нужно делать, руководствуясь еще одним принципом из Zen of Python: «явное лучше неявного».
К сожалению, у такого подхода есть обратная сторона. Software complexity problem, с которой боремся мы, программисты. Python как язык похож на кочан капусты, и его простота, это лишь внешний слой. Но чем глубже разработчик погружается, тем больше всякого разного предлагает язык программирования. В глубине его сокрыт инструментарий, чтобы делать действительно большие проекты. Там есть метапрограммирование, декораторы, куча специализированного синтаксиса, огромная стандартная библиотека. Python, который используется в больших проектах на миллионы строк кода, это не тот Python, которому обучают на курсах «войти в IT». Язык прост в начале, но чем больше мы используем этот инструмент, тем больше разных фишечек он нам предоставляет, чтобы мы могли создавать сложный софт.
Python очень хорошо документирован
Когда я в 90-х начинал писать код, для меня золотым стандартом документации был MSDN, который действительно объяснял, как правильно программировать под Windows. Другой пример хорошей документации — это Qt, там было множество примеров, после несколько сотен страниц становилось понятно, что вообще делать. Сейчас документация Python вобрала в себя все лучшее за последние 30 лет.
Python документирован очень хорошо. Не только сам язык, его синтаксис, семантика, но и стандартная библиотека. На официальном сайте огромное количество примеров в разделе документации. Новый разработчик прочтет там не только «что», но и «как». А опытный разработчик найдет нюансы использования с примерами, сможет сразу посмотреть, как правильно.
Python имеет в комплекте «батарейки»
В стандартной библиотеке Python более 200 модулей для того, чтобы работать с данными, работать с форматами файлов, отсылать и принимать почту. Огромное количество штук Python может сделать «из коробки».
У «батареек» есть обратная сторона. Стандартная библиотека очень быстро устаревает и, к примеру, та ее часть, которая связана с сетевыми запросами, уже много лет назад была заменена мега популярной библиотекой Requests.
Недавно в комьюнити Python была неприятная ситуация, когда один из очень известных контрибьюторов сделал библиотеку для того, чтобы декораторами просто и читаемо описывать структуры данных. Дальше он поговорил с Гвидо, в стандартной библиотеке сделали простенькую альтернативу dataclasses. После чего автор изначальной библиотеки начал получать сообщения типа: «Нафига ты этот велосипед изобретаешь, если в стандартной библиотеке все есть?». Но в стандартной библиотеке это очень простенькая штучка, а он делает полнофункциональную.
Есть когнитивное искажение, что если что-то есть в стандартной библиотеке, то не надо изобретать велосипед. Поэтому наличие этой огромной стандартной библиотеки в какой-то мере тормозит развитие Python. Она маскирует наличие альтернатив. Условно, когда мы в гугле ищем, как распаковать zip-архив в Go, то мы сразу видим библиотеки, которые делают это правильно. С Python мы сразу видим стандартную библиотеку. Даже если эта часть устарела на 10-20-30 лет, альтернативы еще надо поискать.
Python очень популярен в науке
Есть мнение, которое я часто встречал в аналитике и у знакомых питонистов. Возможно, Python популярен в науке не потому, что он делает для науки что-то особо крутое. Возможно, он популярен, потому что ученые — это не программисты.
Гвидо сделал Python как клей для доступа ко всяким системным штукам. Python с самого начала хорошо мог в C, C++, Fortran — а это как раз то, что в те времена использовали ученые для работы с данными и экспериментами. Ученым нравилась простота изучения Python, им дальше простого первого слоя языка копать не было необходимости. А когда ученые начали использовать язык, он проник в образование и получилось самоподдерживающееся пророчество: учёные используют Python, обучают своих студентов, те из них, кто остается в образовании, тоже используют Python в обучении. Так за 30 лет Python очень надежно проник в науку.
Синтаксис многих популярных решений для Python, например, numpy, близок математикам. Сейчас считается, что Python это инструмент по умолчанию для ML и Data Science, что это привычный инструмент для математиков, ведь за десятилетия этого самоподдерживающегося пророчества выросла огромная экосистема для работы с данными и ML: TensorFlow, AirFlow, Pandas и множество других систем.
Python медленный
Python интерпретируемый язык программирования. Но сейчас интерпретируемость это совсем не то, что было 30 лет назад. Тогда говорили, что Basic интерпретируемый, и подразумевали, что есть некая программа «basic», которая берет текст программы на языке программирования Basic, построчно читает, разбирает и выполняет.
С современными языками программирования это, конечно, не так. Все современные языки программирования компилируемые. Просто некоторые, например, Java, сперва компилируется в байт-код, а потом виртуальная машина Java этот байт-код компилирует в машинный код. Или, как в случае С или Rust, у них нет виртуальной машины, семантика чуть беднее, поэтому они сразу компилируются из текста в машинный код.
Python компилируется из текста в байт-код и далее виртуальная машина Python, программа python.exe
, этот байткод выполняет. Байт-код — это маленькие инструкции, каждая из которых делает какую-то часть работы программы. Для Python они довольно хорошо оптимизированы, как и его виртуальная машина. Она не компилирует машинный код, потому что пока есть виртуальная машина, язык может обеспечить гораздо более богатую семантику, чем то что нам предлагает, к примеру, JavaScript.
Виртуальная машина сама по себе медленная, это не машинные коды, это все-таки программа, которая выполняет байт-коды. А еще есть Global Interpreter Lock (GIL). Виртуальная машина Python предпочитает одновременно выполнять байткод python только в одном потоке. Это придумано для того, чтобы можно было сделать очень быстрый сборщик мусора и защитить структуры данных в памяти от конкурентного использования.
Это не значит, что Python не может выполнять код параллельно. Он не может свой байт-код выполнять параллельно, а чужой нативный код может. Как только байткод начал делать что-нибудь системное, например, читать из файла, или писать в сетку, он поднимает GIL, и какой-то другой поток может начать выполнять высокоуровневую логику байткода. Плюс, стандартная библиотека позволяет хорошо раскладывать Python на процессы. Но все это не мешает ему быть в худшем случае раз в сто-двести медленнее, чем С.
Python популярен в вебе
Python не самое популярное решение для веба, однако многие питонисты делают фулстек веб-приложения, и еще большее количество программистов делают на Python свои API.
Почему так, почему не PHP? Потому что в конце нулевых Python как раз начал замещать PHP и Perl, вышел фреймворк Django, который вдохновился очень популярным тогда фреймворком Ruby on Rails. Считается, что Django взял лучшие моменты из Rails и добавил традиционно хорошую документацию. А Гвидо с 2005 года начал работать в Google над App Engine. И это считается одной из ключевых вех в популярности Python, потому что язык стал пиарить Google, как язык «по умолчанию» чтобы делать веб-приложения для Google App Engine. Python занял нишу между PHP и Java, когда PHP уже слишком мало, а Java это слишком много.
За Django последовали другие фреймворки, но в начале десятых случился современный фронтенд, к нам пришли React, Angular, Vue и сожрали фронтендовую часть фулстека. Но в 2019 году Python немного отыгрался FastAPI, о котором поговорим чуть ниже.
У Python беда с управлением зависимостями
Десятки лет назад библиотеки для Python жили на сайте Vaults of Parnassus. Каждая библиотека была архивом с текстовичком о том, как ее добавлять свою программу. В 1998 году разработчики в версии 1.6 языка добавили в стандартную библиотеку модуль distutils
, который ввёл понятие distribution package — zip-архив, который можно скачивать и устанавливать в виде install package
.
С установкой приняли спорное решение, которое во многом прокляло зависимости Python. Авторы посмотрели на огромный архив Vaults of Parnassus и решили, что заставлять каждого разработчика приводить библиотеки к общему виду никто не будет. Придумали, что в install package
будет файл setup.py
, и его просто будут запускать. А в файл setup.py
разаработчики зависимостей сами напишут какой-то код, который будет ставить зависимость, как написано в текстовичке. Копировать нужные файлы в какие-то директории, вносить необходимые изменения. А дальше то, что поставилось, уже можно использовать в своем коде. Главная проблема была в том, что setup.py
мог выполнять любой Python-код, и поэтому когда сейчас мы делаем pip install
, начинают выполняться все setup.py
файлы, и мы не представляем себе, какие зависимости поставятся, что поменяется, и что вообще произойдет.
Сообщество Python пытается побороть эти сложности, но язык редко определяет работу с зависимостями. Например, npm это не часть JavaScript, Maven это не часть стандарта Java, gem до недавнего времени не был частью Ruby, composer не часть PHP.
Так выглядит экосистема работы с зависимостями Python в 2022 году:
Это популярные тулзы, которые сейчас используются, чтобы управлять зависимостями в Python. И, на секундочку, у Python есть логотип сложности управления зависимостями — Утконос. Представляете, у языка есть логотип того, насколько сложно управлять зависимостями!
Python взял лучшее из статического и динамического типизирования
Традиционно типы считают крутым инструментом, чтобы сократить число ошибок в программах. И Википедия согласна, что типы — это чтобы было меньше багов. Динамическое и статическое типизирование, это про то, кто расставляет типы, «капканы для ошибок». В случае динамического типизирования типы расставляет язык программирования, в случае статического — программист.
У динамического типизирования традиционным плюсом было то, что так как язык за нас расставляет типы, мы можем со страшной скоростью писать код. Минусом было то, что капканы срабатывают, как правило, не сразу, а на этапе выполнения. Иногда капканы могут вообще не поставиться.
В статически типизированном языке код пишется медленнее, потому что нужно руками расставлять капканы. Rust в этом плане особенно показателен. Например, я расставил три капкана, которые мне интересны, и говорю ему, ну ты там остальные сам выведи, а Rust такой: «Я не понимаю, что там, давай, ты мне уточнишь». Я смотрю, и тоже не понимаю, что там. Ну и дальше идет получасовая сессия в попытке натянуть код на глобус. Зато при статическом типизировании капканы срабатывают сразу.
Python ввёл Gradual Typing — лучшее из обоих миров, когда мы в начале фигачим без типов (их расставляет язык), а потом, когда код стабилизируется, добавляем типы только там, где надо. Это позволяет иметь в программах существенно меньше багов и высокую скорость разработки одновременно.
Современный Python часто использует типы не только для того, чтобы расставлять капканы для ошибок, но и не по назначению. Например, pydantic, популярная сейчас библиотека для работы с данными.
То, что после двоеточия, это типы, и они используются в качестве DSL, чтобы описать данные. Мегапопулярный FastAPI теперь точно так же использует типы, чтобы описывать API. Как в Ruby DSL использовался 20 лет назад, чтобы писать лаконичный, идиоматичный код, так сейчас программисты на Python научились использовать типы, чтобы писать такой же лаконичный и идиоматичный код.
Какой Python сейчас,…
Python поддерживается крупнейшими мировыми IT-компаниями. Он уже развивается не одним человеком, много лет избираемый steering council из нескольких core-разработчиков работает над языком.
У Python стабильный цикл релизов поддержки, end of life, security фиксов. В Python регулярно появляются новые фичи, в 3.10 появился, например, pattern matching, что очень круто.
Разработчики Python стараются демонтировать устаревшую стандартную библиотеку, изучают возможности отказа от GIL, сейчас есть даже работающая версия, которая убирает GIL и при этом работает быстрее.
Внедряется асинхронность, Django и Flask не так давно перешли на асинхронные рельсы, и активно делаются решения, которые на одном ноутбуке позволяют легко держать 10 тысяч асинхронных подключений в секунду.
И, конечно же, идет битва с зависимостями. Есть pipenv, которое пытается как npm в NodeJS, чтобы npm install
, или как gem в Ruby, gem install
, чтобы одной командой все работало.
… и каким он станет в будущем
Есть две ключевые идеи, которыми я бы хотел завершить свой рассказ. Во-первых, сайт Real Python, который содержит исчерпывающую, крутейшую документацию о Python. Это сотни обучающих статей, каждую из которых писали несколько разработчиков и редактировали несколько редакторов. Наверно, лучшее по обучению, что сейчас есть в мире, и при том бесплатно. Они зарабатывают деньги на видеоуроках, но тексты бесплатны.
Во-вторых, Python из-за его легкости в изучении, распространении в образовании и сильной позиции в современной разработке, стал де-факто языком для того чтобы «войти в IT». И многие HR говорят, что это очень сильно размывает пул разработчиков. Из сотни откликов на вакансию питониста людей с опытом больше пяти лет не так много, а большинство окончили трехмесячные курсы и хотят войти в IT. Есть опасение, что вот эта мегапопулярность может серьезно пошатнуть позиции Python. Или нет?
Комментарии (47)
Xtray
30.08.2022 13:42Python самый популярный язык программирования в мире
Можно эту мысль раскрыть подробнее? А то в таком виде заявление несколько расходится с данными, приведёнными в других статьях, например: https://habr.com/ru/post/651585/
grigoryvp Автор
30.08.2022 14:20+1Этих индексов - как грязи, https://www.tiobe.com/tiobe-index/python/ ????
Xtray
30.08.2022 14:41+3Поэтому и хочется понять, на какой ориентироваться и почему :)
Вот гитхабовский: https://octoverse.github.com/#top-languages-over-the-yearsSergioShpadi
30.08.2022 16:52+4TIOBE - это бредовый индекс, измеряющий популярность по гугл-запросам. По его данным, например, Visual Basic гораздо популярнее JavaScript, а Delphi популярнее Golang. Гитхабовский индекс основан на реальном использовании кода на Гитхабе и гораздо ближе к реальности.
nagayev
31.08.2022 09:14+2Мой вам совет: забейте на все эти индексы. Изучайте то, что вам больше нравится и ищите работу в этой сфере.
Если это что-то из C,C++,C#,Java, Go, Python, Ruby, JavaScript то вы наверняка найдете работу.
prishol
31.08.2022 10:25Рейтинг Stackoverflow за 2021 год. Есть удобная навигация по годам и можно смотреть динамику insights.stackoverflow.com/survey/2021
MentalBlood
30.08.2022 14:19+3библиотеку для того, чтобы декораторами просто и читаемо описывать структуры данных
Что за библиотека то??)
zueve
30.08.2022 14:23Есть pipenv, которое пытается как npm в NodeJS, чтобы
npm install
, или как gem в Ruby,gem install
, чтобы одной командой все работало.По моему все уже давно перешли на poetry, (по крайней мере бекендеры)
Strohmann
30.08.2022 14:33+4А чем лучше-то? А то мы не перешли. Бегло посмотрел poetry каких-то киллер-фич не увидел.
zueve
30.08.2022 15:40+1Для меня киллер фича - то, что через poetry можно публиковать библиотеки в pypi, плюс ресолв зависимостей на много быстрее (был по крайней мере когда последний раз сравнивал)
Dair_Targ
30.08.2022 18:52+2Не, далеко не все. Например в моей текущей конторе споткнулись о проблемы с авторизацией в приватных pypi (нужный сценарий не поддерживался). В итоге pip, и полет нормальный.
SergioShpadi
30.08.2022 17:02Когда работаешь с Python, кажется, что он сделан в отрыве от всех накопленных человечеством до его создания знаний. Самая странная особенность Python - нарушение функцией map функторных законов, что делает невозможным нормальную композицию функций.
Во всех нормальных языках map(List<X>, x => x) == List<X>, в Python же map(List<X>, x => x) нужно обернуть в функцию list(), чтобы получить исходный массив. Безумие какое-тоwhoisking
30.08.2022 17:39+6Вполне нормальное поведение возвращать итерируемый объект, делая само вычисление ленивым, чтоб экономить память. Не знаю за все языки, но в дарте практически такая же реализация.
osmanpasha
30.08.2022 18:02+10Надо просто думать о функции map как о принимающей iterable, а не список, тогда все становится на места. То, что вы ей подаёте конкретный подкласс iterable, не меняет того, что она вернет iterable.
lair
30.08.2022 22:53+1Во всех нормальных языках
map(List<X>, x => x) == List<X>
Видимо, C# тоже не относится к нормальным языкам.
Sayonji
30.08.2022 23:19Да только js и php нормальные языки, остальные сделаны в отрыве от накопленных человечеством знаний.
SergioShpadi
31.08.2022 08:04Видимо, так. А вот в F# оно реализовано верно.
Функтор map пришел в языки программирования из математики. И согласно математическому определению он должен удовлетворять двум законам:
map id = id map (f . g) = map f . map g
Без следования этим двум законам композиция функций не работает.
lair
31.08.2022 14:35Я боюсь, что ваше "должен" (в смысле, "вот это что-то под названием
map
в программировании должно вести себя так же, как функторmap
в математике) — оно ваше собственное, а не универсальное.
fishHook
31.08.2022 11:16+1Давайте для начала определимся, что такое List. В разных языках это: интерфейс коллекций (Java), неизменяемый связный список (Haskell, Scala), вектор (C#, python)
Какой из этих подходов принят как эталонно нормальный?
PokimonZerg
30.08.2022 20:57+1Python неплох для небольших скриптом.
Возможно даже для машинного обучения, где все это тоже небольшие скрипты.
На нем даже можно микросервисы писать.
Но как по мне, язык рождён с проблемами. Динамическая типизация добавляет сложности. Управление зависимостями и сборка сделаны кривенько. Кроссплатформенность хромает.
Сейчас есть языки лучше. Java Kotlin. И Python нечего им противопоставить
God_and_code
30.08.2022 22:12+2Динамическая типизация, так как она реализована в Python наоборот является преимуществом, это очень хорошо раскрыто Григорием.
Adilet-novichok
30.08.2022 22:12+2В питоне можно ставить типы, даже дженерики. Деплою на Heroku без каких-либо проблем с зависимостями. На питоне есть достаточно большие проекты.
В машинном обучении точно маленькие скрипты?
StSav012
31.08.2022 08:45+2Это почему кроссплатформенность хромает? Нечасто, но использую Python на телефоне, не говоря про настольные системы разной архитектуры и на разных процессорах.
PokimonZerg
31.08.2022 09:17-2Многовато python завязано на библиотеки ос и реализацию в нативном коде.
По этому скрипт написанный на windows как правило не запустится на linux без пары настроек. Вот. Полно таких вопросов. https://stackoverflow.com/questions/61465311/python-script-works-on-windows-but-not-in-linux
Толи делов Java. Где тот же код работы с excel написан тоже на Java. Потому работает везде
StSav012
31.08.2022 15:11Ну не знаю. В предъявленном Вами случае всё покрыто мраком NDA, а человек джва года не может сфабриковать подобные файлы, но с выдуманным содержимым.
В списке Related однако нет ни одного вопроса о совместимости Python, кроме драйверов ФС, что не совсем про Python.
Покажите случай, когда нужна именно пара настроек.
FreeNickname
30.08.2022 22:41+1Спасибо за статью! Полезно собрать какие-то базовые вещи в одном месте (типа того же списка утилит для управления зависимостями с пояснениями, как там вообще состояние экосистемы сейчас).
Например, я расставил три капкана, которые мне интересны, и говорю ему, ну ты там остальные сам выведи, а Rust такой: «Я не понимаю, что там, давай, ты мне уточнишь». Я смотрю, и тоже не понимаю, что там.
Сейчас очень холиварно будет, но может быть проблема в том, что Вы написали код, который сами не понимаете? По крайней мере читается это так. Если что, мне нравится Python, хотя работал с ним не так много, но просто вот конкретно этот тезис прямо очень странный :)
grigoryvp Автор
31.08.2022 11:56+2Сейчас очень холиварно будет, но может быть проблема в том, что Вы написали код, который сами не понимаете
Все так. Только вот для других языков это не проблема. Понимать весь код, который пишет разработчик - это довольно накладно. Обычно мы понимаем те части, которые нам важны. А все остальное "разберись сам". Gradual typing позволяет при первоначальном быстром прототипизировании очень быстро фигачить код, понимая только ключевые части. И далее по мере необходимости уточнять детали.
FreeNickname
31.08.2022 11:58+3Я боюсь, я не понимаю, как можно не понимать код, который пишешь. Как тогда вообще его писать? Может Вы могли бы привести пример фрагмента, где понимание своего кода не принципиально, и при этом накладно?
grigoryvp Автор
31.08.2022 13:31+2Изи. Когда я пишу users.add(user), то мне совершенно неинтересно какой "под капотом" контейнер "users", как именно реализовано "add", когда и за кем придет сборщик мусора. Я сосредоточен на решении бизнес задачи - мне нужно сохранить объект, отвечающий за пользователя, в контейнер. Линтеры, профилировщики и прочая инфраструктура должна помогать мне, если мой код для языка/фреймворка/стека неоднозначен, может быть неправильно понят, потечет памятью или еще что. Держать все это в человеческой памяти и самостоятельно следить за мелочами... ну, такое. Зачем доверять человеку то, что может сделать программа?
А gradual typing позволяет мне после стабилизации кода зайти и указать, какой контейнер я ожидаю или какой протокол должен поддерживать user, если для меня это важно. А если не важно - то могу не приходить. В отличии от Rust и C++, где объяснять детали придется в любом случае, важно для нас это как для разработчика или не важно.
FreeNickname
31.08.2022 15:09Любопытно. Видимо, я слишком долго пишу на статически типизированных языках :) Мне всё равно трудно представить такой подход, но я понимаю, что он может быть удобным. Но мне пришлось бы переучиваться на такую модель мышления :) Спасибо!
UPD: хотя всё равно ситуация, когда Вы сами смотрите на код, и не понимаете, что там должно быть, когда компилятор ругается, кажется неправильной: на мой взгляд, в этом случае всё-таки код не до конца продуман, и даже в менее строгом языке его пришлось бы в итоге как-то переписывать, потому что Вы столкнулись бы с теми же проблемами, но позже.
Daddy_Cool
31.08.2022 11:51Какая книжка рекомендуется для освоения Питона?
Поясню вопрос. Есть много языков которые вполне можно использовать как языки э... общего назначения. Т.е. я пишу на Си, и мне в общем хорошо. Но скорее всего есть масса вещей которые легко и просто делатся на Питоне, а на Си - долго и нудно. Вот и хочется что-то где бы были рассмотрены задачи именно хорошо подходящие для Питона.
cutwater
31.08.2022 12:40Если у Вас есть опыт языка Си и знание английского, то будет достаточно прочитать официальный туториал [1] и дальше уже пользоваться официальной документацией [2].
В противном же случае могу порекомендовать книги Изучаем Python, Марк Лутц (довольно объемное обстоятельное чтиво) или "Укус Питона" (A Byte of Python).
grigoryvp Автор
31.08.2022 13:32+1Если хороший английский то настоятельно рекомендую realpython.com, о котором писал в статье и рассказывал в докладе. Лучшее из того, что случилось с обучением программированию за последние десяток лет.
Biga
Интересно. Теперь ясно, почему в питоне некоторые вещи сделаны как из Zope.
grigoryvp Автор
FastAPI старается всё исправить)
whoisking
Что-то исправляет, а что-то добавляет. Некоторые странные баги висят годами, пайдантик часто не может сказать в каком конкретном поле ошибка, отдавая просто "422 unprocessable entity", документации по апи так и нет. Но с другой стороны, над ним по сути и работает то только 1 человек...
Nasreddin_Hodja
А мне не нравится роутинг через декораторы, не понимаю зачем многие фреймворки так делают, Flask тот же. Вот джанговский подход мне нравится.
grigoryvp Автор
Концепция "single file", "все в одном месте". Для простых и средней сложности сценариев (под которые заточено FastAPI) это удобнее, чем сотня роутов в отдельном файле. А вот когда роутов больше тысячи - наоборот становится удобнее их централизованно хранить в отдельном месте как в Django.
Nasreddin_Hodja
Так ведь в джанге не централизованно, в смысле не все роуты в одном месте. Есть главный роутер (root urlconf в терминологии джанги), а оттуда роуты могут инклюдиться. Например у подключённого модуля могут быть свои роуты, в таком случае инклюдитcя роутер этого модуля. При этом при необходимости роуты сторонних модулей можно переопределить, если хочется чтобы ссылки выглядели по другому. Получается очень гибко.