Оправдания: 1) про синглтон. Выпилил и согласен, что инстанциировать джобы стоит

в 1 месте -> синглтон в помойку. Скрин 1 — решение проблемы. Норм? В самом регистраторе джоб не вижу проблем.

2) Оправдаюсь, что тройку я не тыкал и пока бест-практисы из нее отложим. Со всем остальным, не указанным в вопросах, я понял что не так сделал и займусь фиксом.

Вопросы:
1) Наследование и БД: у нас есть базовый класс DB, который определяет базовое поведение любого интерфейса взаимодействия с базой. На данный момент реализовано пробрасывание извне sessionmaker. Почему вышеописанное неверно с точки зрения наследования?
2) i18n. Я так понимаю, что он является стандартом де-факто. А что если предполагается 1 язык в боте? Не является ли i18n, в первую очередь, как инструмент для реализации мультиязычности, оверинжинирингом, а если является, что юзать вместо него, не храня втупую string-ами в .py?
3) Я сейчас занимаюсь реализацией 2 точек входа в аппку: стандартная (__main__) и cli, который будет надстройкой и всякое уметь: стадия проекта (dev/prod), polling / webhook etc. Верна ли идея или должна быть только 1 точка входа?
4) Нормально ли создавать таблички через Base.metadata.create_all?
5) Loguru: слышал отзывы и «за» и «против» него. Хотелось бы еще и ваше мнение, желательно аргументированное. Из того, что я слышал против логуру: лишняя зависимость, сложно встраивать параллельно с logging (а мне этого и не надо), мол медленно работает.
6) Специфика генератов и памяти. 2 скрин. Я правильно реализовал генератор получения юзеров? Или там один хрен с листом по потреблению будет?
7) Класс, вложенный в класс — почему плохо? А как же Base?

скрины где

не влезло. Нужный скрин приложил.

5. Не видел адекватных аргументов "за". Как правило это неумение написать logging.basicConfig. В остальном это дикий тормоз для твоего приложения

5. Вот тут тред: https://t.me/ru_python/1574161

Понял, спасибо

1) Вопрос в том, почему класс ORM и класс с методами юзера (по сути запросы к бд) - это наследник и родитель 2) Fluentogram и точка 3) Проект не должен знать нихуя про продакшн или dev 4) пойдёт 5) мне похуй, даю добро.Главное в либы не пихай 6) Нелимитированные запросы - плохо 7) У Тишки есть материал на эту тему

О, напомнил, как думаешь, стоит ли к питон боту приделать OpenTelemetry чтоб вообще пиздец

Я приделал, но он включается только в дев среде. Ибо пиздец процессору в проде

2) А как тогда менеджерить версии проекта (dev/prod)? UPD: юзкейс: 2 бота: 1 в проде, другой в локалке для тестирования. При деплое просто меняем значение с dev на prod и проект дергает другой конфиг.

не накручиваю ничего специального в само приложение максимум это пару метрик прометеуса и то редко если нужна статистика - рисуются графики по логах

Снаружи

Откуда «снаружи»? CLI — это снаружи, но тогда проект знает про свою версию..

подменяй енвы

Ну, телеметрия (читай егерь) больше для разбора боли с общением между сервисами. Я вот пока не решил что мне поможет корректно это мониторить. Сентри меньше ест, но мне наглядная

Окей, подумаю как это не через жопу реализовать

Пайдантик сеттингз. А дальше хочешь енвы, хочешь секреты - он всё жрёт из коробки

Покоммитить в твой репо что ли...

хоть динаконф и он еще больше форматов из коробки кушает

Кстати, а можно ли пайдантик заменить на что-то более быстрое

Если ты про чтение конфигурации, то он очень просто кэшируется и все :)

я в целом про тройку, где пайдантик везде

и да, нахуя кэшировать конфиги

датаклассы динаконфом парсишь, собираешь в датаклассы

https://t.me/aiogram_ru/1192997

Чтобы не ходить за ними в енв каждый раз...

по секрету (не секрет) скажу что в 4.0 планирую выпиилить pydantic

ну ахуеть задержки при том что конфиги читаются пару раз

абстрактные 3 нсек умножаем на 300кк рпс, получаем пару часов задержек на чтение конфигов

на четвёрке мои внуки будут писать, мне бы как-то в обход, пораньше

Не используй, чё пристал)

а нахуя конфиг каждый апдейт читать

чем плох условный class Pizdos: def __init__(self, **kwargs) -> None: self._configure(kwargs) def _configure(self, cfg: Dict[str, str]) -> None: ... def reconfigure(self, cfg: Dict[str, str]) -> None: self._configure(cfg) Тут конечно лишний метод, но суть в целом ясна конфиг надо в датакласс ещё поменять чтоб прям хорошо

Какие-то лишние нагромождённости. Проще надо быть

И взять dataclass-factory?

по желанию

cattrs

Чем лучше?

вкусовщина

А подскажи ещё фичей под четвёрку, буду форк пилить

а почему не в 3.0?

Потом смёрджишь, ничё

В пятерке, я считаю, что и мидлвари нужно выпилить

Зачем?

Непонятно в какой момент и когда запускается какой код, нерационально и нелинейно

По порядку, хз что не линейно

на этапе бета-теста такое изменение поздно делать

Слышал паттерн декоратор?

жаль(

он не в восторге от выпиливания фабрики фильтров

Ты мою иронию так и не понял?

Вот зачем она нужна была я сразу не понимал

чтобы ракушки приходящие из телебота могли писать text="text", но круче

А ее выпилили?

в пине есть описание

Да ладно

Неужели ради такой мелочи форк делать