Я не пользовался `zally`. По описанию, они делают очень разное. Насколько я понял, он используется для валидации и «лучших практик». А `schemathesis` используется для тестирования.
Для тех, кто интересуется темой работы с `ast` в Python, можно посмотреть на пример реализации преобразований в реальном проекте: мы делаем самый строгий линтер для Python.
Любителям функционального стиля и python – предлагаю посмотреть на замечательную библиотеку returns, где реализованы основные монады (+типизация) и разные полезные вспомогательные штуки для работы с ними. Очень помогает делать простые вещи – просто.
Там есть все из списка, но и еще куча дополнительных ништяков вроде: `wemake-python-styleguide`, `mypy`, правильный набор плагинов для `pytest`, `poetry` для управления зависимостями, куча всего для безопасности (`bandit`, `safety`, `snyk`)
Спасибо за видео и статью! К сожалению, не смог посетить доклад лично.
Задам вопрос пост-фактум.
> Есть функции, которые принимают позиционные аргументы. Если аргументов достаточно много, то при их вызове функции не очень понятно, где какой аргумент и зачем он нужен.
У меня была похожая идея для своего линтера: github.com/wemake-services/wemake-python-styleguide/issues/340
Но она разбилась о факт наличия `*args` в языке. Как вы решаете проблему того, что некоторые функции могут и должны принимать много позиционных аргументов by design?
Там есть:
— Типизированные пайплайны: returns.readthedocs.io/en/latest/pages/pipeline.html
— Типизированный `partial` и `curry`: returns.readthedocs.io/en/latest/pages/curry.html
Внезапно оказалось, что разработчикам на Python слова вроде «Монада», «Функтор» и уж тем более «Апликативный функтор» – не знакомы совсем.
Потому мы пришли к другому решению: выкинуть все сложные слова. И заменить их более интуитивно понятными. Монада = контейнер. Функтор = Mappable.
А все объяснения «зачем?!» строить через решение понятных практических задач. Например:
— Монады можно использовать для обработки ошибок вместо исключений
— А еще для внедрения зависимостей
— Ну и чтобы писать асинхронный код!
На мой взгляд — сработало отлично! Многие только потом узнали, куда они ввязались.
Вот тут наши преобразования: github.com/wemake-services/wemake-python-styleguide/tree/master/wemake_python_styleguide/transformations
— github.com/wemake-services/wemake-django-template
— github.com/wemake-services/wemake-vue-template
Любителям функционального стиля и python – предлагаю посмотреть на замечательную библиотеку returns, где реализованы основные монады (+типизация) и разные полезные вспомогательные штуки для работы с ними. Очень помогает делать простые вещи – просто.
Там есть все из списка, но и еще куча дополнительных ништяков вроде: `wemake-python-styleguide`, `mypy`, правильный набор плагинов для `pytest`, `poetry` для управления зависимостями, куча всего для безопасности (`bandit`, `safety`, `snyk`)
Кстати про Python. Туда тоже начинают проникать похожие идеи и подходы: habr.com/ru/company/oleg-bunin/blog/445234
Задам вопрос пост-фактум.
> Есть функции, которые принимают позиционные аргументы. Если аргументов достаточно много, то при их вызове функции не очень понятно, где какой аргумент и зачем он нужен.
У меня была похожая идея для своего линтера: github.com/wemake-services/wemake-python-styleguide/issues/340
Но она разбилась о факт наличия `*args` в языке. Как вы решаете проблему того, что некоторые функции могут и должны принимать много позиционных аргументов by design?