Вопрос относительно структуры бота. Если у меня есть функция генерирования инлайн

клавиатуры, она должна быть в том же файле, что и соответсвующий хэндлер? Или можно ее вынести в отдельный файл/папку с другими клавиатурами и импортировать? Просто там же calback_data?

Куда хочешь

Просто импортируй её из другого файла

просто импорт и все? А колбэкдата подтянется сама?

Смотри по нескольким факторам. Во-первых, у тебя по-любому не один хендлер и не одна клавиатура. Если ты делаешь всё в отдельных файлах, будь последовательным, делай так со всеми хендлерами. И наоборот. Во-вторых, ты должен ориентировать по тому, насколько у тебя раздулся файл. Если он всё ещё хорошо читаем, делай в одном. Если раздулся, выноси

Я за разделение ответственности. Можешь архитектурку чекнуть. Вообще главное — это здравый смысл. Тело (логика) хендлера должна читаться максимально просто; не стоит мешать бизнес-логику и view-слой. То есть api и коннекты к базы уж 100% не имеют права в теле хендлера лежать. Далее, если эта инлайн клавиатура может использоваться только этим хендлером и дублирования кода в будущем не будет, то можешь ее в файл с хендлером положить. Это концепцию разделения ответственности ломает не критично

Я тут глянул твой шаблончик... 1) Почему в переменных окружения явно указан вендор БД.Если бд изменится, то надо ещё и переменные окружения везде менять. Чем плох префикс db_ - непонятно 2) Мелкие косяки по пеп8, в частности по пустым строкам 3) зачем нужен bot["db"] когда тройка умеет в кварги диспетчера 4) Scheduler() и _register_schedulers() выглядит как пиздец 5) Нет гарантии (обещания) что при остановке бота все апдейты будут исполнены т.к. системные сигналы сразу останавливают бота. 6) Лоад конфиг с LRU кэшем. 7) Какого-то хуя приложение знает, в проде оно работает или нет. Этого ему знать не надо. 8) Вложенные классы - зло 9) Дублировать код как здесь - плохо 10) Почему методы работы с юзером из БД реализованы отдельно, а класс - наследник... 11) Блядский синглтон 12) Тексты реплик бота сохранены в .py файлах - очень сильно пиздец.Уж лучше использовать Fluentogram. 13) Модуль кастомных эксепшенов - и нет ни одного.WTF... 14) Ручное указание типов апдейтов для диспетчера когда тройка умеет сама их находить 15) Константа RATE LIMIT в реализации троттлинга - этот параметр следует пробрасывать извне. Оставляю за собой право не заметить что-то сразу и добавить позднее.

Типа на KeyboardInterrupt? Не очень понял.

А вообще помимо эксепшенов там и другие болячки

о, видел шаблон в англоязычном чате плосую под замечаниями

Да, читаю и перевариваю. Буду исправлять)

А что скажешь по поводу эксепшена для выхода?

каком из? я не просматривал глубоко

try: asyncio.run(main()) except (KeyboardInterrupt, SystemExit): # Log this is pointless pass

ну это еще может быть

Я в какой-то момент осознал что это ж пиздец. У нас есть апдейты, которые уже обрабатываются? Да поебать!Выходим! Нет бы Graceful Shutdown, чтоб хендлер на системные эксепшены (если сигнал нормальный, не девятка какая-нибудь) аккуратно отключал диспетчер, проверял какую-нибудь in-memory очередь вроде arq, что всё обработано, и уже потом гасил базу и так далее