На больших проектах с пачкой плагинов flake8 может спокойно и 30 секунд отрабатывать и минуту, а ruff останется так же вменяемым по времени ответа. Плюс такие мелкие куски времени решают в прекоммит-хуках и на нагрузку ci-cd воркеров для больших компаний.
Там из коробки включено очень мало правил. Перед тем чтобы они что-то проверили - их нужно будет в конфигурации включить. Плюс есть большая и понятная табличка, какие правила стабильные, какие в эксперементальном режиме, какие считаются устаревшими.
Gil не используется для однопоточного приложения, которым и является asyncio Однопоточное приложение будет медленнее на 10% процентов с собранным интепритатором no-gil
Конечно же язык должен развиваться для людей раз в 9 лет запускающих скриптики и ни в коем случае не должен соответствовать современным трендам использования языка. Тем более как появится новая версия интерпретатора без гила, то все старые в интернете удалят и никак нельзя будет скачать.
Стоит упомянуть, что в случае асинхронного кода в приложениях, прометиус клиент использует под капотом синхронный open и позволяет качественно сломать себе копчик в самых неожиданных местах https://prometheus-async.readthedocs.io/en/stable/index.html
Привет, проект выглядит очень заманчиво и перспективно. Хотелось бы предложить идею, так как искали на своем проекте, но подобного не нашли - swagger-подобная документация, чтобы можно было в автоматическом режиме смотреть какие очереди с какими параметрами и сообщениями обрабатываются
Alpine для питона не стоит использовать - https://habr.com/ru/post/486202/ Так же есть сценарий, что под альпин будут пропущены бинарные зависимости, для того же pydantic
В питоне есть сахар, который я встречаю очень редко по упрощению вложенных if, но я практически никогда не видел его в коде. Пример будет очень условным, но тем не менее:
data = 54
data_is_not_none = data is not None
data_bigger_then_50 = data > 50
if data_is_not_none and data_bigger_then_50:
print("Yeah!")
В целом, это достаточно холиварный момент. Общего соглашения в виде pep'a нет, кто-то использует, кто-то нет.
Но это сильно портит читаемость кода и потихоньку приходят к решению, что это — антипаттерн.
Маленькие замечания по питону:
1)lambda — синтаксис для анонимных функций и используются однократно, например в сортировках. Если нужно переиспользовать, то стоит обьявлять синтаксис с def.
2)Внутри f-строк не стоит производить вычисления и/или вызовы функций, желательно передавать уже готовые значения.
3)В питоне есть красивый синтаксический сахар в виде генераторов выражений, который позволяет не использовать нагромождение map|filter|lambda
На больших проектах с пачкой плагинов flake8 может спокойно и 30 секунд отрабатывать и минуту, а ruff останется так же вменяемым по времени ответа.
Плюс такие мелкие куски времени решают в прекоммит-хуках и на нагрузку ci-cd воркеров для больших компаний.
Там из коробки включено очень мало правил. Перед тем чтобы они что-то проверили - их нужно будет в конфигурации включить. Плюс есть большая и понятная табличка, какие правила стабильные, какие в эксперементальном режиме, какие считаются устаревшими.
Если собираетесь только под игры, то строго рекомендуется все таки x3d, так как там скачок в качестве игр значителен
Gil не используется для однопоточного приложения, которым и является asyncio
Однопоточное приложение будет медленнее на 10% процентов с собранным интепритатором no-gil
Конечно же язык должен развиваться для людей раз в 9 лет запускающих скриптики и ни в коем случае не должен соответствовать современным трендам использования языка.
Тем более как появится новая версия интерпретатора без гила, то все старые в интернете удалят и никак нельзя будет скачать.
Стоит упомянуть, что в случае асинхронного кода в приложениях, прометиус клиент использует под капотом синхронный open и позволяет качественно сломать себе копчик в самых неожиданных местах
https://prometheus-async.readthedocs.io/en/stable/index.html
Привет, проект выглядит очень заманчиво и перспективно. Хотелось бы предложить идею, так как искали на своем проекте, но подобного не нашли - swagger-подобная документация, чтобы можно было в автоматическом режиме смотреть какие очереди с какими параметрами и сообщениями обрабатываются
Protected на уровне соглашения - в любой произвольной версии интерфейс может поменяться и ты можешь использовать только на свой страх и риск.
Alpine для питона не стоит использовать - https://habr.com/ru/post/486202/
Так же есть сценарий, что под альпин будут пропущены бинарные зависимости, для того же pydantic
https://flakeheaven.readthedocs.io/en/latest/
Обвязка вокруг flake для красоты с возможностью отключения отдельных правил у отдельных плагинов
В питоне есть сахар, который я встречаю очень редко по упрощению вложенных if, но я практически никогда не видел его в коде. Пример будет очень условным, но тем не менее:
Отличный топик по питону, а не очередной перевод. Спасибо!
Без iter уже не итератор
https://docs.python.org/3/library/collections.abc.html#collections.abc.Iterator
https://pip.pypa.io/en/stable/cli/pip_wheel/
На сервере-сервере сборщике:
pip wheel --wheel-dir /tmp/wheels -r requirements.txtНа офлайн-сервере, после копирования wheels через флешку:
p
ip install ./wheels/*
requirements.txt можно получить с помощью poetry.Ну и сам детерминированный
Стандартный источник pypi.org. Можно указывать свои кастомные.
Насчет формата не скажу, про предполагаю, что стандарт сейчас wheels.
В примере с многоэтапной сборкой передается в образе билдера, переменные как-нибудь передаются в финальный образ?
Но это сильно портит читаемость кода и потихоньку приходят к решению, что это — антипаттерн.
1)lambda — синтаксис для анонимных функций и используются однократно, например в сортировках. Если нужно переиспользовать, то стоит обьявлять синтаксис с def.
2)Внутри f-строк не стоит производить вычисления и/или вызовы функций, желательно передавать уже готовые значения.
3)В питоне есть красивый синтаксический сахар в виде генераторов выражений, который позволяет не использовать нагромождение map|filter|lambda