А пробовал его? По документации он прям восхитительный

чуть-чуть

ага только к нему еще Единорога надо )

А если верить документации то он еще и свагер вытаскивает

и для реддока тоже )

И какой это легковесный получаеться?

он генерит swagger-like доку

ему нужен только старлет и пидантик

ну и ASGI сервер

Про зависимости крутое есть.
Коллега притащил в проект google-auth.
Зачем-то в зависимостях у него есть setuptools >=40.5.0
Причём внутри самого пакета setuptools ни разу не импортируется и никак не используется.
Было решено обновлять все зависимости.
Теперь сломано примерно всё

Каюсь...Был не прав

CherryPY:

bash -c "du -sb test"
56599438        test

fastapi + uvicorn:

bash -c "du -sb test"
34505931        test

Base:

bash -c "du -sb test"
31706527        test

fastapi + uvicorn легче (((

Забавно:-(

по факту fastapi нифига не легче, в смысле написания и отладки, особенно кто привык к фласку и иже с ним.
Например, если вы захотите нормально логировать запросы (со всеми параметрами query string / body /form), то придется сильно заморочиться.
Фактически fastapi  асинхронный, но иногда выглядит как синхронный, что может больно ударить.
Другая боль, "искоробки" он ловит только определенный эксепшен, а я привык к иерархии  аля:

class ApiError():
   xxxx

class NotFound(ApiError):
   status = 404
   message = "xxx"

class NotFoundFile(ApiError):
   ...
   def __init__(filename):
    yyy

И для того чтобы сделать как я люблю, мне приходится писать мидлварю, причем в fastapi их два типа. Так вот надо писать самую суровую, в которой асинхронные recv / send.
Плюс фастапи рекламируется как супер быстрый. Так вот, это гребанная ложь. Бенчмарк которым аффтор хвастается, специально написан "низкоуровнего" под бенчмарк и не использует свои возможности. По сути в бенчмарке используется голый uvicorn с тончайшей оберткой starlette.

Но вот swagger "искоробки" это прикольно.

class ApiError():
   xxxx

class NotFound(ApiError):
   status = 404
   message = "xxx"

class NotFoundFile(ApiError):
   ...
   def __init__(filename):
    yyy

А чем тебе такой вариант не угодил?

https://fastapi.tiangolo.com/tutorial/handling-errors/#install-custom-exception-handlers

Потому что там в коде проверка в коде именно на конкретный эксепшен. На потомки он уже не сработает.
Там внутри сохраняется тип эксепшена и хендлера в словарь.
И когда райзится эксепшен делает проверка аля:

  if exc in exceptions:
      ...

Основной сценарий использования эксепшенов, который в доках прописан это такой:

if что то плохое:
   raise HttpException(status_code=404, details="file not found")

То есть ты в каждом месте где генеришь эксепшен должен передать и код и сообщение и это всё разбросано по тысячам местам бизнеслогики.
А например когда ты пишешь клиента к своему вебсерверу, хочется заранее знать все возможные эксепшены котоыре бэк может кинуть и их структуру (ведь во многих ошибках возвращается еще какие то детали: какой параметр не верный, какой файл не найден, запрос сделан из не поддерживаемой страны (вернется и текущая страна клиента и список разрешенных стран) и т.д.)

if что то плохое:
   raise HttpException(status_code=404, details="file not found")

там можно указать, какие экспешены возвращает хендлер

мне все 200 штук указывать?