А сколько в нем команд? И будут ли ещё в будущем? От этого отталкиваться. Обычно в ботоводстве принято создавать по обработчику для каждой команды. Дальше уже самому смотреть как удобнее. Если их (команд) много, прям очень много - можно вообще их подгружать динамически, выведя их в отдельную папку handlers, и не нагромождать файл с точкой старта (а то как обычно бывает - просто bot.py на 500+ строк). Проще и поддерживать, и добавлять новые команды/функционал.
Как обходной вариант можете виртуалку поставить. За банковские приложения не скажу - не проверял, но мессенджеры и тп вообще не проверяют на вшивость среду, где они запускаются.
Сам давно пользуюсь этим способом
Были т.н. пользовательские боты (userbot), где можно автоматизировать всё что захотите. От пересылки сообщения до триггеров на само событие удаления сообщения и текущего статуса собеседника ("печатает"). Ищите в ту сторону.
. Я когда-то пользовался и перестал, авторы, да и сам основной контингент этих юзерботов вызывает мягко говоря только отвращение. Хотя это ИМХО.
з.ы. А вот что не ИМХО - это то что там очень часто воруют аккаунты.
Если происходит жонглирование одного объекта между функциям, то почему бы не завернуть их все в единый класс? И обращаться к нему как к атрибуту экземпляра?
Глобальный поиск пропатчили. Ненадолго вернули, и опять забрали. Возвращают выборочно (t.me/botlist)
ИМХО судя по посту Дурова, они уже навсегда оставят себе премиальные (@ casino, @ market) и другие пятизначные для дальнейшей продажи в своей очередной крипто ху-не, и выпустят в свободное плавание остальные имена. По срокам только неизвестно
Большинство библиотек для http общения могут работать с одним заранее сконфигурированным экземпляром Клиента. В requests это requests.Session, а в httpx например httpx.Client
Ищите где в вашей апи инициализируется Клиент и попробуйте переопределить его своим