>> Сообщество дурачков.
> Причем тут язык, если вся проблема, что вы выбрали ту работу, которая вам не заходит

Вот именно про такую дурацкость в сообществе я и пишу.

Проблемы, которые я описал в п.1 - п.4 - это проблема именно языка, его интерпретатора и его стандартной библиотеки. Они не привязаны к моей работе лично или чьим либо проектам вообще. Наоборот, эти проблемы усложняют написание качественного и быстрого кода на питоне!

Сейчас это убогий по скорости, нестандартизированный, некроссплатформенный язык без поддержки сериализации не умеющий толком ничего кроме REST. Тут даже "jack of all trades" и универсальность языка не аргументы, потому что кто мешал написать стандарт байткода при переходе от 2 к 3? Кто мешал написать SAX-парсер для классов питона? Кто мешал прикрутить аннотирование к функциям и конструкторам?

Это тот самый случай культивирования культа карго. Питонисты не понимают, зачем это всё нужно, поэтому выкаблучиваются про то что "задача не та", "проект не тот", "работа не та" и прочее "не нужно". Они реально не понимают, потому что не видели задач. А задачу перед ними никто не ставит, потому что язык ни черта не умеет и спроектирован комитетом. Его "архитектура" нечто среднее между С++ и COBOL по мерзотности. При этом авторы не меняют ничего, потому что нет запроса на изменение. Это средневековье, мрак и культ карго.

Я, без шуток, проще найду общий язык на эту тему с разработчиками 1С. Они пусть и знают что они "погромисты" одной платформы, но им не нужно объяснять, что такое DTO и почему некоторые проливки лучше делать через SOAP. И про отчеты знают.

> Проблема не в языках, а в прямых руках кодеров и мозгах архитекторов.

Вот тебе одна из таких историй. Собственно та самая, когда проект от аутсорсера перевалили мне.
Наняла фирма как-то 8 лет назад (по глупости) группу как выяснилось позже питон-разрабов (2 пацана / ИП), которых попросила написать модуль отчетности для нескольких корпоративных АТС (телефонные продажи и саппорт). В форме внутрикорпоративного вебсайтика и задачей в стиле "вы сами лучше знаете как это писать, мы вам скажем что в выводимых таблицах".

При этом она этим аутсорсерам исправно платила за работу. И программа работала первые 2 года. Но как и любая отчетность эта тоже не стояла на месте. Были заказаны и оплачивались доработки на изменения отчетов и доработки на добавление новых отчетов. Со временем росло напряжение, потому что внезапно они не захотели поддерживать свой собственный продукт ни за какие вменяемые деньги! А когда их попросили помочь добавить их базу в ETL, чтобы сделать общий кубик (OLAP), эти придурки сбежали в истерике, разругались и не захотели больше работать, благо свой код они отдали без конфликта. Вот такое барахло мы с пацанами и переписывали на .NET, благо смогли найти контакт с истеричными аутсорсерами через год после того как они слились (у них реально был нервный срыв тогда от объема задач по этой статистике).

Казалось бы, а почему так, да? А потому что Python + Django + PostgreSQL.
- Когда ты используешь язык, который не работает по-нормальному ни с какой сериализацией, то каждый дополнительный ендпоинт обмена данными - это рукописный ад.
- Когда ты используешь MVC-фреимворк, то бизнеслогика отчетов смешана с техническим кодом и сопровождать это, когда много изменений логики и добавляются источники - сущий ад. Причем Django - "нитакиекаквсе" , они даже свое MVC называют иначе, просто потому что придурки^W "python way".
https://docs.djangoproject.com/en/4.2/faq/general/#django-ap...
Но это все равно MVC со всеми его плюсами и минусами.
- PostgreSQL - пожалуй самая плохая из всех возможных баз данных, когда дело доходит до визуализации и предварительной трансформации отчетности, пусть даже OLTP. Она пухнет, она тупит от Time Series, ей кластеризация - это набор костылей. И вот когда из этого барахла нужно кубы строить, то она понятное дело сама пролить данные и трансформировать не умеет. И в те годы не было Apache Airflow или был, но был молод. В общем кончилось это все переписыванием на ASP.NET Core + Angular + MSSQL для функициональных компонентов из которой проливалось все в PowerBI где были отчеты и дашборды наряду с другими отчетами компании.

Мораль: не используйте Python и его фреимворки для динамичных внутрикорпоративных проектов. Вы сами же и выгорите, пока будете это сопровождать. Python - это вещь в себе, он плохо интегрируется, требует много рутинного бойлерплейта, всё переименовывает и делает "по своему" просто чтобы отличаться, плохо работает вне Linux и еще и жутко медленный.