Comments 50
Интересно. Теперь ясно, почему в питоне некоторые вещи сделаны как из Zope.
FastAPI старается всё исправить)
Что-то исправляет, а что-то добавляет. Некоторые странные баги висят годами, пайдантик часто не может сказать в каком конкретном поле ошибка, отдавая просто "422 unprocessable entity", документации по апи так и нет. Но с другой стороны, над ним по сути и работает то только 1 человек...
А мне не нравится роутинг через декораторы, не понимаю зачем многие фреймворки так делают, Flask тот же. Вот джанговский подход мне нравится.
Концепция "single file", "все в одном месте". Для простых и средней сложности сценариев (под которые заточено FastAPI) это удобнее, чем сотня роутов в отдельном файле. А вот когда роутов больше тысячи - наоборот становится удобнее их централизованно хранить в отдельном месте как в Django.
Так ведь в джанге не централизованно, в смысле не все роуты в одном месте. Есть главный роутер (root urlconf в терминологии джанги), а оттуда роуты могут инклюдиться. Например у подключённого модуля могут быть свои роуты, в таком случае инклюдитcя роутер этого модуля. При этом при необходимости роуты сторонних модулей можно переопределить, если хочется чтобы ссылки выглядели по другому. Получается очень гибко.
В FastAPI тоже можно без декораторов.
Этот код
@app.get("/")
def get_root():
...можно разделить на определение функции и вызов
app.get("/")(get_root)Так что при желании можно сделать почти как в Django: список (метод, путь, функция), которые потом регистрируются парой строк. Кода для этого нужно совсем немного.
Но как уже сказал Григорий, в небольших задачах, где FastAPI особенно удобен, нужды в этом нет, да и читать проще.
В Flask роутинг тоже можно настраивать отдельно. Просто в примерах обычно простенькие сайты, где роутинг удобнее через декораторы для наглядности.
Python самый популярный язык программирования в мире
Можно эту мысль раскрыть подробнее? А то в таком виде заявление несколько расходится с данными, приведёнными в других статьях, например: https://habr.com/ru/post/651585/
Этих индексов - как грязи, https://www.tiobe.com/tiobe-index/python/ 😂
Поэтому и хочется понять, на какой ориентироваться и почему :)
Вот гитхабовский: https://octoverse.github.com/#top-languages-over-the-years
TIOBE - это бредовый индекс, измеряющий популярность по гугл-запросам. По его данным, например, Visual Basic гораздо популярнее JavaScript, а Delphi популярнее Golang. Гитхабовский индекс основан на реальном использовании кода на Гитхабе и гораздо ближе к реальности.
Мой вам совет: забейте на все эти индексы. Изучайте то, что вам больше нравится и ищите работу в этой сфере.
Если это что-то из C,C++,C#,Java, Go, Python, Ruby, JavaScript то вы наверняка найдете работу.
библиотеку для того, чтобы декораторами просто и читаемо описывать структуры данных
Что за библиотека то??)
dataclasses в комплекте и attrs от Хинека
Есть pipenv, которое пытается как npm в NodeJS, чтобы
npm install, или как gem в Ruby,gem install, чтобы одной командой все работало.
По моему все уже давно перешли на poetry, (по крайней мере бекендеры)
А чем лучше-то? А то мы не перешли. Бегло посмотрел poetry каких-то киллер-фич не увидел.
Мелочи в основном. В pyproject.toml можно конфиги других утилит централизованно складывать. pip умеет ставить проекты с pyproject.toml сразу с гитхаба итд.
Для меня киллер фича - то, что через poetry можно публиковать библиотеки в pypi, плюс ресолв зависимостей на много быстрее (был по крайней мере когда последний раз сравнивал)
Не, далеко не все. Например в моей текущей конторе споткнулись о проблемы с авторизацией в приватных pypi (нужный сценарий не поддерживался). В итоге pip, и полет нормальный.
Простите, я думал все используют virtualenv в связке с pip, я устарел?
Когда работаешь с Python, кажется, что он сделан в отрыве от всех накопленных человечеством до его создания знаний. Самая странная особенность Python - нарушение функцией map функторных законов, что делает невозможным нормальную композицию функций.
Во всех нормальных языках map(List<X>, x => x) == List<X>, в Python же map(List<X>, x => x) нужно обернуть в функцию list(), чтобы получить исходный массив. Безумие какое-то
Вполне нормальное поведение возвращать итерируемый объект, делая само вычисление ленивым, чтоб экономить память. Не знаю за все языки, но в дарте практически такая же реализация.
Надо просто думать о функции map как о принимающей iterable, а не список, тогда все становится на места. То, что вы ей подаёте конкретный подкласс iterable, не меняет того, что она вернет iterable.
Во всех нормальных языках map(List<X>, x => x) == List<X>Видимо, C# тоже не относится к нормальным языкам.
Да только js и php нормальные языки, остальные сделаны в отрыве от накопленных человечеством знаний.
Видимо, так. А вот в F# оно реализовано верно.
Функтор map пришел в языки программирования из математики. И согласно математическому определению он должен удовлетворять двум законам:
map id = id
map (f . g) = map f . map g
Без следования этим двум законам композиция функций не работает.
Давайте для начала определимся, что такое List. В разных языках это: интерфейс коллекций (Java), неизменяемый связный список (Haskell, Scala), вектор (C#, python)
Какой из этих подходов принят как эталонно нормальный?
Python неплох для небольших скриптом.
Возможно даже для машинного обучения, где все это тоже небольшие скрипты.
На нем даже можно микросервисы писать.
Но как по мне, язык рождён с проблемами. Динамическая типизация добавляет сложности. Управление зависимостями и сборка сделаны кривенько. Кроссплатформенность хромает.
Сейчас есть языки лучше. Java Kotlin. И Python нечего им противопоставить
Динамическая типизация, так как она реализована в Python наоборот является преимуществом, это очень хорошо раскрыто Григорием.
В питоне можно ставить типы, даже дженерики. Деплою на Heroku без каких-либо проблем с зависимостями. На питоне есть достаточно большие проекты.
В машинном обучении точно маленькие скрипты?
Это почему кроссплатформенность хромает? Нечасто, но использую Python на телефоне, не говоря про настольные системы разной архитектуры и на разных процессорах.
Многовато python завязано на библиотеки ос и реализацию в нативном коде.
По этому скрипт написанный на windows как правило не запустится на linux без пары настроек. Вот. Полно таких вопросов. https://stackoverflow.com/questions/61465311/python-script-works-on-windows-but-not-in-linux
Толи делов Java. Где тот же код работы с excel написан тоже на Java. Потому работает везде
Ну не знаю. В предъявленном Вами случае всё покрыто мраком NDA, а человек джва года не может сфабриковать подобные файлы, но с выдуманным содержимым.
В списке Related однако нет ни одного вопроса о совместимости Python, кроме драйверов ФС, что не совсем про Python.
Покажите случай, когда нужна именно пара настроек.
Спасибо за статью! Полезно собрать какие-то базовые вещи в одном месте (типа того же списка утилит для управления зависимостями с пояснениями, как там вообще состояние экосистемы сейчас).
Например, я расставил три капкана, которые мне интересны, и говорю ему, ну ты там остальные сам выведи, а Rust такой: «Я не понимаю, что там, давай, ты мне уточнишь». Я смотрю, и тоже не понимаю, что там.
Сейчас очень холиварно будет, но может быть проблема в том, что Вы написали код, который сами не понимаете? По крайней мере читается это так. Если что, мне нравится Python, хотя работал с ним не так много, но просто вот конкретно этот тезис прямо очень странный :)
Сейчас очень холиварно будет, но может быть проблема в том, что Вы написали код, который сами не понимаете
Все так. Только вот для других языков это не проблема. Понимать весь код, который пишет разработчик - это довольно накладно. Обычно мы понимаем те части, которые нам важны. А все остальное "разберись сам". Gradual typing позволяет при первоначальном быстром прототипизировании очень быстро фигачить код, понимая только ключевые части. И далее по мере необходимости уточнять детали.
Я боюсь, я не понимаю, как можно не понимать код, который пишешь. Как тогда вообще его писать? Может Вы могли бы привести пример фрагмента, где понимание своего кода не принципиально, и при этом накладно?
Изи. Когда я пишу users.add(user), то мне совершенно неинтересно какой "под капотом" контейнер "users", как именно реализовано "add", когда и за кем придет сборщик мусора. Я сосредоточен на решении бизнес задачи - мне нужно сохранить объект, отвечающий за пользователя, в контейнер. Линтеры, профилировщики и прочая инфраструктура должна помогать мне, если мой код для языка/фреймворка/стека неоднозначен, может быть неправильно понят, потечет памятью или еще что. Держать все это в человеческой памяти и самостоятельно следить за мелочами... ну, такое. Зачем доверять человеку то, что может сделать программа?
А gradual typing позволяет мне после стабилизации кода зайти и указать, какой контейнер я ожидаю или какой протокол должен поддерживать user, если для меня это важно. А если не важно - то могу не приходить. В отличии от Rust и C++, где объяснять детали придется в любом случае, важно для нас это как для разработчика или не важно.
Любопытно. Видимо, я слишком долго пишу на статически типизированных языках :) Мне всё равно трудно представить такой подход, но я понимаю, что он может быть удобным. Но мне пришлось бы переучиваться на такую модель мышления :) Спасибо!
UPD: хотя всё равно ситуация, когда Вы сами смотрите на код, и не понимаете, что там должно быть, когда компилятор ругается, кажется неправильной: на мой взгляд, в этом случае всё-таки код не до конца продуман, и даже в менее строгом языке его пришлось бы в итоге как-то переписывать, потому что Вы столкнулись бы с теми же проблемами, но позже.
Какая книжка рекомендуется для освоения Питона?
Поясню вопрос. Есть много языков которые вполне можно использовать как языки э... общего назначения. Т.е. я пишу на Си, и мне в общем хорошо. Но скорее всего есть масса вещей которые легко и просто делатся на Питоне, а на Си - долго и нудно. Вот и хочется что-то где бы были рассмотрены задачи именно хорошо подходящие для Питона.
Если у Вас есть опыт языка Си и знание английского, то будет достаточно прочитать официальный туториал [1] и дальше уже пользоваться официальной документацией [2].
В противном же случае могу порекомендовать книги Изучаем Python, Марк Лутц (довольно объемное обстоятельное чтиво) или "Укус Питона" (A Byte of Python).
Если хороший английский то настоятельно рекомендую realpython.com, о котором писал в статье и рассказывал в докладе. Лучшее из того, что случилось с обучением программированию за последние десяток лет.
Крутая статья, читал на одном дыхании. Спасибо!
Мифы и легенды современного Python