кстати, про flask я уже как-то отвечал, после появления FastAPI, вообще не вижу в нем надобности, считай что он устарел, как когда-то давно устарел tornado, сейчас у меня выбор django или FastAPI, ну и иногда aiohttp, когда разработка под телеграм.
Ну коммон, я уточняющий вопрос задал как раз чтобы получить хоть какую-то конкретику, а не повторение голословного утверждения. Уязвимости выявляются у всего подобного софта, популярные без проблем их закрывают, про какие-то "проблемы с безопасностью" у FastAPI я не слышал, учитывая что он у меня в проде, больше чем 2-3 года.
"научному сообществу" как раз пофиг на ООП и "ООП в стиле джавы" (откуда вообще такой вывод, в питоне ООП точно не в стиле java, а если учесть еще и то что он появился раньше java) в частности. Это сообщество, как раз часто пишет код в стиле write only, надо решить текущую задачу, решил и пошел дальше, поддерживать, то что нафигачил не нужно. "Научному сообществу" нужен простой синтаксис и куча доступных библиотек, что и предоставил python
Используйте существительные во множественном числе для коллекций. /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
я тоже давно их использую, но мой коммент совсем про другое, что хватит поверхностных статей или того что легко прочитать в доках, хотелось бы про опыт, неочевидные проблемы и их решения, интересные или новые кейсы.
кстати, про flask я уже как-то отвечал, после появления FastAPI, вообще не вижу в нем надобности, считай что он устарел, как когда-то давно устарел tornado, сейчас у меня выбор django или FastAPI, ну и иногда aiohttp, когда разработка под телеграм.
Ну коммон, я уточняющий вопрос задал как раз чтобы получить хоть какую-то конкретику, а не повторение голословного утверждения. Уязвимости выявляются у всего подобного софта, популярные без проблем их закрывают, про какие-то "проблемы с безопасностью" у FastAPI я не слышал, учитывая что он у меня в проде, больше чем 2-3 года.
даже стало интересно что это за проблемы с безопасностью у FastAPI?
"научному сообществу" как раз пофиг на ООП и "ООП в стиле джавы" (откуда вообще такой вывод, в питоне ООП точно не в стиле java, а если учесть еще и то что он появился раньше java) в частности. Это сообщество, как раз часто пишет код в стиле write only, надо решить текущую задачу, решил и пошел дальше, поддерживать, то что нафигачил не нужно. "Научному сообществу" нужен простой синтаксис и куча доступных библиотек, что и предоставил python
Например, "write only". И почему-то этот идеальный клей, уступил python свое место в linux окружении.
Про python декораторы на хабре было 100500 статей, от вообще никаких, до супер крутых, после которых можно было вообще эту тему закрыть.
А для какой цели в пункте 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
я тоже давно их использую, но мой коммент совсем про другое, что хватит поверхностных статей или того что легко прочитать в доках, хотелось бы про опыт, неочевидные проблемы и их решения, интересные или новые кейсы.