Используйте существительные во множественном числе для коллекций. /users.
красиво, но спорное, /user и /user/{id} может быть реализовано шаблонно, соответственно для /users требуется написание дополнительного кода, да и потребителю проще будет дописать к /user идентификатор, я чем использовать разные строки.
Используйте JSON и HTTPS. Это не обсуждается.
тут смешали две разных сущности, https вообще сбоку делается и да, не обсуждается, а json это просто представление данных, при правильном проектирование меняться без проблем практический на любой другой, и да, бывают редкие случаи, когда основным требуется какой-то другой формат.
Еще стоит упомянуть про разницу /user и /user/ если при GET еще можно без проблем сделать редирект, то с POST это уже проблемно.
Если говорить конкретно про эту тройку, то вообще не вижу смысла выбирать под какую-то задачу Flask, оставившие два полностью удовлетворят потребность в большинстве задач.
Конечно не стоит, но пока достаточное количество людей упорно продолжают это делать (тут должно быть известная картинка про jwt и сессии, но она уже надоела)
На данный момент, в новых проекта pytest.ini и requirements.txt фактически не используются, а определяются в pyproject.toml, да и куча старых делают этот перенос
if 'birthdays' in data and data['birthdays']:
birthday_data = data['birthdays'][0]
if 'date' in birthday_data:
bdate_dict = birthday_data['date']
try:
year = bdate_dict.get('year')
if year:
...
стоит сокращать такие ступеньки if, например так (превращать в одну цепочку нескольких .get не стал)
if (
(birthday_data := data.get('birthdays', [{}])[0]) and
(bdate_dict := birthday_data.get('date')) and
(year := bdate_dict.get('year'))
):
...
Проверить auth_date: если метка времени слишком старая (например, более нескольких минут), данные могут быть недействительными.
А не сталкивались с такой проблемой, что прилетает auth_date сильно старая (больше суток)? Общее для всех таких, user agent содержит "CPU iPhone OS 16_далее_все_подверсии"
Можно сказать что уже нет, он перешел к astral, а uv стал его "преемником" (successor project). Из нового интересного, astral начали новый проект type checker - ty
я тоже давно их использую, но мой коммент совсем про другое, что хватит поверхностных статей или того что легко прочитать в доках, хотелось бы про опыт, неочевидные проблемы и их решения, интересные или новые кейсы.
А слухи сообщают какую-то конкретику? я вот наоборот все включаю и только потом отключаю, причем отключаю спорные, а не те, которые код ломают, навскидку такие сейчас уже и не вспомню.
aiogram тянет aiohttp, там отличный http клиент, получается что httpx лишняя зависимость, так же раньше aiohttp уделывал его по скорости, но как с этим сейчас, не знаю, возможно уже доработали
Капитанство какое-то. Ну и везде одни "Преимущества", а как насчет недостатков? Например, set теряет порядок, сложные comprehensions не улучшат читаемость, а сделают наоборот.
именно устанавливает, правда не знаю как именно устанавливает conda, но будет именно версия которой нет в системе, а, ну и установка конечно же будет не системная, что правильно, системный python лучше ставить только пакетными менеджерами системы
А для какой цели в пункте 5 переопределять get_queryset? list_select_related именно это же уже и делает.
даже стало интересно, почему ЯП, в котором 1 == '1' false, "еще менее типизирован", чем ЯП в котом это true?
красиво, но спорное, /user и /user/{id} может быть реализовано шаблонно, соответственно для /users требуется написание дополнительного кода, да и потребителю проще будет дописать к /user идентификатор, я чем использовать разные строки.
тут смешали две разных сущности, https вообще сбоку делается и да, не обсуждается, а json это просто представление данных, при правильном проектирование меняться без проблем практический на любой другой, и да, бывают редкие случаи, когда основным требуется какой-то другой формат.
Еще стоит упомянуть про разницу /user и /user/ если при GET еще можно без проблем сделать редирект, то с POST это уже проблемно.
так в fastapi и синхронные обработчики можно указывать, хотя конечно я не разбирался как они влияют на процесс обработки запроса в ASGI сервере.
хм, а какие специфичные требования в "обвязка для ML-сервиса", из-за которых стоило бы выбрать именно Flask, а не FastAPI?
Если говорить конкретно про эту тройку, то вообще не вижу смысла выбирать под какую-то задачу Flask, оставившие два полностью удовлетворят потребность в большинстве задач.
Конечно не стоит, но пока достаточное количество людей упорно продолжают это делать (тут должно быть известная картинка про jwt и сессии, но она уже надоела)
Основная проблема JWT в SPA, после всех нужных "доп. реализаций" он уже не Stateless.
На данный момент, в новых проекта pytest.ini и requirements.txt фактически не используются, а определяются в pyproject.toml, да и куча старых делают этот перенос
выставляю настройку
select = ["ALL"]а за ним вignoreдописываю, обычно со временем, меня не устраивающиестоит сокращать такие ступеньки if, например так (превращать в одну цепочку нескольких .get не стал)
А не сталкивались с такой проблемой, что прилетает auth_date сильно старая (больше суток)? Общее для всех таких, user agent содержит "CPU iPhone OS 16_далее_все_подверсии"
Можно сказать что уже нет, он перешел к astral, а uv стал его "преемником" (successor project). Из нового интересного, astral начали новый проект type checker - ty
я тоже давно их использую, но мой коммент совсем про другое, что хватит поверхностных статей или того что легко прочитать в доках, хотелось бы про опыт, неочевидные проблемы и их решения, интересные или новые кейсы.
Начались одинаковые статьи про ruff и uv, ничего нового. Всё таки хотелось бы более глубокого анализа этих инструментов.
А слухи сообщают какую-то конкретику? я вот наоборот все включаю и только потом отключаю, причем отключаю спорные, а не те, которые код ломают, навскидку такие сейчас уже и не вспомню.
aiogram тянет aiohttp, там отличный http клиент, получается что httpx лишняя зависимость, так же раньше aiohttp уделывал его по скорости, но как с этим сейчас, не знаю, возможно уже доработали
Капитанство какое-то. Ну и везде одни "Преимущества", а как насчет недостатков? Например, set теряет порядок, сложные comprehensions не улучшат читаемость, а сделают наоборот.
именно устанавливает, правда не знаю как именно устанавливает conda, но будет именно версия которой нет в системе, а, ну и установка конечно же будет не системная, что правильно, системный python лучше ставить только пакетными менеджерами системы
кому что удобно, тот то и использует, вообще не вижу тут проблемы