https://www.techempower.com/benchmarks/#section=data-r21&l=zijzen-6bj Примерно там же где и fastapi. Ну и скорость эта конечно относительная - отстает от многих других языков/фреймворков, но я очень сомневаюсь что async python недостаточно быстрый для большинства бизнес приложений.
что такое email.email? каким образом Verified появляется на объекте? что мешает не вызвать проверку Verified когда функцию переиспользуют в новом месте?
Рекомендаций по ORM не дам - у нас просто асинхронный коннектор к БД и круды. Необходимости делать множественные джойны отсутствует, так как основной объект имеет часть инфы как binary-json (postgres). Часть реляционной схемы съедена, что имеет свои минусы и плюсы. Год назад проверял по алхимии и она было только частично async, сейчас вроде они полностью мигрировали. Есть асинхронные ORM вроде tortoise, не пользовался по серьезному. Тредпул это просто имитация асинхронности для блокирующего кода. Условно у нас есть эндпоинт который читает с базы и допустим делает запрос куда-нибудь, функция которая делает запрос уже написана и использует requests - блокирующую либу. Мы делаем threads.deferToThread (это в twisted, в асинкио есть аналоги) и задачка помещается в очередь на выполнение тредпулом. Запрос это IO задача, то есть поток сразу уходит спать пока не получит ответ. Проблема с GIL может быть только для CPU-bound задач. Возможно потому что ORM у нас нет - проблем с загрузкой процессора тоже нет
Питон в продакшене у огромных контор и вполне себе работает. О серьезных проектах на flask или других threaded-wsgi в прочем сейчас уже речь не идет. Либо django для батерек из коробки, либо что-то асинхронное - fastapi, starlite и тд. Все асинхронные либы используем сразу, синхронные пихаем в тредпул.
Ну, есть же fastapi, twisted и другие решения. У нас на twisted + klein приложение обрабатывает миллионы запросов в сутки, не вижу особых мотиваторов на что-то переезжать.
Когда легко можно привести контр пример - это означает что тезис слишком общий. Windows конечно не идеальная ОС, но она объективно хороша по многим параметрам. Не буду аппелировать к своему опыту, но например J Blow, доволен Windows куда больше чем Linux, хотя обе системы плохи в части GUI. Если вы, например, адепт С++, и не понимаете почему индустрия влюблена в Python - возможно это вы не понимаете чего-то. ( Например J Carmack активно использует Python в работе) Опять таки, я не утверждаю что C++ чем либо хуже. Но вероятнее всего для обычной работы вроде автоматизации какого-нибудь простого процесса, либо вебсайта - маловероятно что C++ более удачный инструмент. То же самое и для АКПП. Возможно часть людей и выигрывает больше от механики, но значительному большинству ездить на АКПП безопаснее, проще и эффективнее. ... При желании всегда можно воткнуть коробку в manual
1) Почему же? Большинство ходит в обуви вместо того чтобы ходить босиком. Так ли оно не право? 2) Это 164 км в день, похоже на такси. Думаю у вас все же межгород режим. Возьмем фуры как ультимативный пример - большинство современных тягачей на АКПП 3) Автоматизация двигатель прогресса, нравится вам это или нет
Будем честны - большинство не обслуживает узлы самостоятельно. Замена масла раз в 60 тыс я бы не назвал прям сложным обслуживанием. Насчет сложнее сломать - я бы поспорил, что механику сломать проще, т.к. больше шанс выбора несоответствующей передачи.
Зачем ездить на механике, когда есть АКПП? При желании воткнул в ручное управление и тормози двигателем. Если вы не участвуете в ралли, то вероятнее всего механика это избыточный контроль, который в 99% ежедневных ситуаций не нужен.
Хинты работают не только в IDE Они работают как часть проверок в Github Actions или другом инструменте CI. Условно: шаг 1) скачать питон и зависимости, шаг 2) запустить flake, если ошибка стоп шаг 3) запустить тесты, если ошибка стоп, шаг 4) запустить mypy, если ошибка стоп, шаг 5) запушить на s3 если билд удачный https://mypy.readthedocs.io/en/stable/
Тесты не имеют покрытия всех мест где вызывается функция. Тесты не могут проверить что вызывающий использует только "публичные" методы и не руками не изменяет стейт класса. Тесты не проверят что функция которая должна смотреть конфиг не пытается его изменить. Тесты не проверят что вы реализовали__mul и всегда пишете например Price(amount=1.2, currency='RUB') * 0.2 ( где 0.2 скидка). Но вы забыли что можно 0.2 * Price(amount=1.2, currency='RUB') и вам также нужен __rmul и тесты этого не покрыли. И так далее... Только не убеждайте меня что вы все это покроете тестами, этого точно не произойдет =)
Смысловую нагрузку они несут, также как и тесты. Потому что ровно также как и тесты встраиваются в CI и не дают запушить код, который проверку не проходит. Сами предложили противопоставление тестов и типов, сами теперь отрицаете что механизм работы обоих инструментов это дополнительная фича. Что тесты нужно запустить, что типы нужно проверить анализатором. Почему вы рады запускать тесты и включать их в CI, но не рады включить в CI mypy?
Мое замечание направлено в сторону "выявления проблем". Проблемы бывают разные, что я пытался показать на примере тормозов и подушек безопасности. То что тесты работают также не работают в рантайме решили не замечать?
Очень слабо подтвержденный наброс. Ты можешь написать условный выход используя typing.overload. Типы и контракты в типах в коде поддерживает анализатор, который встроен в CI. Как ты вообще притянули сюда раст не очень понятно. "Большая Ржавая Компилятора" связи с типизацией в питоне имеет не больше чем с любым другим языком
"Выявить проблемы" это упрощение: Допустим в автомобиле тормоза - это система для спасения жизни, и подушки безопасности - это система для спасения жизни. Хочется убрать одно из двух? Думаю нет. У меня отношение к типизации-тестированию такое же, убирать одно из двух не хочется. Несмотря на общие цели, более детальный фокус иной.
По поводу исключений я думаю что вопрос спорный. Как по мне это неявная передача контекста выполнения в крайних условиях, без гарантируемой обработки этих крайних условий. Мастадонты индустрии (например разработчик языка D, Александреску) также отмечают проблемы с исключениями. Свое мнение крайней инстанцией не считаю.
Я считаю что типы упрощают а) восприятие (простота) кода, б) изменение (рефакторинг) кода, в) поиск зависимостей и крайних случаев.
И я есть обычный груг, если что-то помогает сдерживать сложность (главный враг груг), учитывая что время есть бесконечность, груг брать типы в свой код!
https://www.techempower.com/benchmarks/#section=data-r21&l=zijzen-6bj
Примерно там же где и fastapi.
Ну и скорость эта конечно относительная - отстает от многих других языков/фреймворков, но я очень сомневаюсь что async python недостаточно быстрый для большинства бизнес приложений.
Любопытства ради - с каким размером кодовой базы вы работаете. Можете померять через tokei
Тест написан до кода? - Написан. Так что под Test-driven подходит. А остальное ваши домыслы
Жалко расставаться с кодом да? Мертвый код - смело удаляем в отдельном PR с говорящим названием. Не нужен этот код про запас, слабая отмазка)
что такое email.email? каким образом Verified появляется на объекте? что мешает не вызвать проверку Verified когда функцию переиспользуют в новом месте?
Рекомендаций по ORM не дам - у нас просто асинхронный коннектор к БД и круды. Необходимости делать множественные джойны отсутствует, так как основной объект имеет часть инфы как binary-json (postgres). Часть реляционной схемы съедена, что имеет свои минусы и плюсы.
Год назад проверял по алхимии и она было только частично async, сейчас вроде они полностью мигрировали. Есть асинхронные ORM вроде tortoise, не пользовался по серьезному.
Тредпул это просто имитация асинхронности для блокирующего кода. Условно у нас есть эндпоинт который читает с базы и допустим делает запрос куда-нибудь, функция которая делает запрос уже написана и использует requests - блокирующую либу. Мы делаем threads.deferToThread (это в twisted, в асинкио есть аналоги) и задачка помещается в очередь на выполнение тредпулом. Запрос это IO задача, то есть поток сразу уходит спать пока не получит ответ. Проблема с GIL может быть только для CPU-bound задач. Возможно потому что ORM у нас нет - проблем с загрузкой процессора тоже нет
Питон в продакшене у огромных контор и вполне себе работает. О серьезных проектах на flask или других threaded-wsgi в прочем сейчас уже речь не идет. Либо django для батерек из коробки, либо что-то асинхронное - fastapi, starlite и тд.
Все асинхронные либы используем сразу, синхронные пихаем в тредпул.
Ну, есть же fastapi, twisted и другие решения.
У нас на twisted + klein приложение обрабатывает миллионы запросов в сутки, не вижу особых мотиваторов на что-то переезжать.
Когда легко можно привести контр пример - это означает что тезис слишком общий.
Windows конечно не идеальная ОС, но она объективно хороша по многим параметрам. Не буду аппелировать к своему опыту, но например J Blow, доволен Windows куда больше чем Linux, хотя обе системы плохи в части GUI.
Если вы, например, адепт С++, и не понимаете почему индустрия влюблена в Python - возможно это вы не понимаете чего-то. ( Например J Carmack активно использует Python в работе)
Опять таки, я не утверждаю что C++ чем либо хуже. Но вероятнее всего для обычной работы вроде автоматизации какого-нибудь простого процесса, либо вебсайта - маловероятно что C++ более удачный инструмент.
То же самое и для АКПП. Возможно часть людей и выигрывает больше от механики, но значительному большинству ездить на АКПП безопаснее, проще и эффективнее.
... При желании всегда можно воткнуть коробку в manual
1) Почему же? Большинство ходит в обуви вместо того чтобы ходить босиком. Так ли оно не право?
2) Это 164 км в день, похоже на такси. Думаю у вас все же межгород режим. Возьмем фуры как ультимативный пример - большинство современных тягачей на АКПП
3) Автоматизация двигатель прогресса, нравится вам это или нет
Будем честны - большинство не обслуживает узлы самостоятельно. Замена масла раз в 60 тыс я бы не назвал прям сложным обслуживанием. Насчет сложнее сломать - я бы поспорил, что механику сломать проще, т.к. больше шанс выбора несоответствующей передачи.
Зачем ездить на механике, когда есть АКПП? При желании воткнул в ручное управление и тормози двигателем. Если вы не участвуете в ралли, то вероятнее всего механика это избыточный контроль, который в 99% ежедневных ситуаций не нужен.
Хинты работают не только в IDE
Они работают как часть проверок в Github Actions или другом инструменте CI.
Условно:
шаг 1) скачать питон и зависимости,
шаг 2) запустить flake, если ошибка стоп
шаг 3) запустить тесты, если ошибка стоп,
шаг 4) запустить mypy, если ошибка стоп,
шаг 5) запушить на s3 если билд удачный
https://mypy.readthedocs.io/en/stable/
Тесты не имеют покрытия всех мест где вызывается функция.
Тесты не могут проверить что вызывающий использует только "публичные" методы и не руками не изменяет стейт класса.
Тесты не проверят что функция которая должна смотреть конфиг не пытается его изменить.
Тесты не проверят что вы реализовали __mul и всегда пишете например Price(amount=1.2, currency='RUB') * 0.2 ( где 0.2 скидка). Но вы забыли что можно 0.2 * Price(amount=1.2, currency='RUB') и вам также нужен __rmul и тесты этого не покрыли.
И так далее...
Только не убеждайте меня что вы все это покроете тестами, этого точно не произойдет =)
Смысловую нагрузку они несут, также как и тесты. Потому что ровно также как и тесты встраиваются в CI и не дают запушить код, который проверку не проходит.
Сами предложили противопоставление тестов и типов, сами теперь отрицаете что механизм работы обоих инструментов это дополнительная фича. Что тесты нужно запустить, что типы нужно проверить анализатором. Почему вы рады запускать тесты и включать их в CI, но не рады включить в CI mypy?
Мое замечание направлено в сторону "выявления проблем". Проблемы бывают разные, что я пытался показать на примере тормозов и подушек безопасности.
То что тесты работают также не работают в рантайме решили не замечать?
так... и?
тесты тоже в рантайме ошибки не ловят
и то, и другое нужно предварительно запустить
Очень слабо подтвержденный наброс.
Ты можешь написать условный выход используя typing.overload.
Типы и контракты в типах в коде поддерживает анализатор, который встроен в CI.
Как ты вообще притянули сюда раст не очень понятно. "Большая Ржавая Компилятора" связи с типизацией в питоне имеет не больше чем с любым другим языком
Как минимум есть разница между
`except`
и
`except Exception`.
Думаю линтит именно первую форму
"Выявить проблемы" это упрощение:
Допустим в автомобиле тормоза - это система для спасения жизни, и подушки безопасности - это система для спасения жизни.
Хочется убрать одно из двух?
Думаю нет.
У меня отношение к типизации-тестированию такое же, убирать одно из двух не хочется. Несмотря на общие цели, более детальный фокус иной.
По поводу исключений я думаю что вопрос спорный. Как по мне это неявная передача контекста выполнения в крайних условиях, без гарантируемой обработки этих крайних условий.
Мастадонты индустрии (например разработчик языка D, Александреску) также отмечают проблемы с исключениями. Свое мнение крайней инстанцией не считаю.
Я считаю что типы упрощают а) восприятие (простота) кода, б) изменение (рефакторинг) кода, в) поиск зависимостей и крайних случаев.
И я есть обычный груг, если что-то помогает сдерживать сложность (главный враг груг), учитывая что время есть бесконечность, груг брать типы в свой код!
С совмещением условий в один if также не согласен с автором, условие стало сложнее и текст набрал плотности