если сложно писать декораторы/не нравятся декораторы, тогда можно использовать классы таким образом, чтобы инстансы классов играли роль функций (ну, т.е. с использованием __call__)

если в FastAPI завезут CBV, он станет 💩 и это будет повод чтобы его выкинуть, сейчас по тестам это самый (!) быстрый фреймворк на питоне, реализующий RESTful API и уступающий раза в 2 (всего лишь!) решениям на Go в синтетических тестах, это не фреймворк для новичков, его задачи быть быстрым в ущерб всему остальному, давая возможность максимально долго оставаться на питоне [и не переходить на Go, например]...

FastAPI - это такой "средний палец", который питонисты могут показать гошникам, когда те начинают разговор о том, что "ваши Django тормознуты, уходите с Python'а, переходите на Go"

пример синтетических тестов: https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=query&l=zijmrj-f

+

И деревянный сруб

Какой ещё средний палец?

это нанотехнологичная стилизация под дерево

ну, очевидно, что достаточно много людей сейчас программируют на Go и на Python смотрят сверху вниз) FastAPI - это такой способ доказать им на практике, что они ошибаются...

вообще, это был намёк на один старый мем с автопроизводителями

А какой смысл сравнивать компилируемый язык с интерпретатором? Понятно что по производительности интерпретатор, тем более с медленной виртуальной машиной уступит компилируемому языку. Зато в компилируемом не будет дженериков (duck typing), не будет метаклассов и т.д. Скорость разработки скорее всего меньше будет.

Либо если "дженерики" и будут то нечто страшное как в С++.

смотря где. джава фиббоначчи быстрее считает, чем с++. чот внезапно, сам не ждал.

Хотя покойный знакомый использовал очень интересный подход, скоростной код писался на Си а интерфейсный UI и для ввода-вывода на Lua.

То есть у него роль дженериков, скриптов играл Lua, а код, требующих высокой скорости вычислений на Си был.

Чем-то отдаленно схоже с Python + Cython. Только оказалось что связка эта сильно недоработана, перекомпилировать каждый раз вручную это неправильно.

Используется наследование. Есть базовый Django CBV взять из БД пользователей или взять из БД список проектов и вывести. И ряд унаследованных, взять только определенных пользователей или определенные проекты. И т.п. Мне кажется что дженерики для этого не лучший вариант. Понятно что можно CBV запихать в обычную функцию view. неужели создание класса такое медленное и сильно замедлит FastAPI.

а что именно доказать? нет смысла сравнивать cpython и go