spataphore, так как телебот синхронный, то если очень хочется long poll, то придётся на тредах. Сделать два треда, в одном будет bot1.polling, в другом bot2.polling.
Например, сделать bot1, bot2, сделать два app.route с токенами обоих ботов, сделать два вызова set_webhook. Тогда каждый бот будет получать запросы на свой адрес и независимо от другого обрабатывать.
Если надо совсем настраиваемо на произвольное число ботов, то придётся отказаться от декораторов и явно регистрировать обработчики для каждого бота. Сделать app.route, в котором по токену находить в словаре инстанс телебота, от которого вызывать process_new_updates.
Технически ничего сложного нет. Если бот на вебхуках, то просто принимаем данные каждого бота на вебхук, делаем независимые обработчики для них. Если на long poll, то на тредах или асинхронно запускаем много polling одновременно. Судя по вопросу, скорее всего, интересует решение для конкретного языка и конкретной библиотеки, но они не названы, недоработочка-с...
Бабка Люда, тут ошибка в том, что функции лучше понимать не как выполняющие действия, а как возвращающие результат в математическом смысле (или в смысле подхода из функционального программирования). То есть если результат функции не нужен для достижения окончательного результата, то её и запускать не нужно, даже если она описана в коде. В реальности, конечно, asyncio не совсем чистое функциональное программирование, но ошибку function was never awaited любой новичок наверняка видел прям в первом же своём эксперименте (фактически она говорит "результат этой функции как конкретное вычисленное значение ни разу не был затребован при выполнении программы / вычислении Главной Функции main").
Бабка Люда, переключение происходит не как попало, а на что-то "следующее" в цикле событий. В данном примере в момент создания таска a() запускается a() и весь код синхронный до await c() в a(); в момент вызова c() запускается именно c() (а не продолжается main(), хотя чисто теоретически реализация могла бы и её запустить без противоречия теории, но говорят, что реально реализация всегда запустит c()) и опять код синхронный до завершения c(), потом опять продолжается a(). Переключение в main() для её продолжения произойдёт только после завершения a().
Все советчики тут советуют asyncio.sleep не просто так: в этом случае и a(), и c() должны будут подождать, и цикл событий точно за время этого ожидания переключится на main() - единственную подходящую для активизации задачу в списке на выполнение.
Roman Kitaev, ну, скажем так, текущая имплементация перебирает цикл определённым образом, который можно посмотреть в сырцах, но это не гарантирует, что это не будет изменено. Да и на более сложных примерах уже ничего не будет так однозначно. Особенно, когда это будет завязано на реальный ввод-вывод - на что, собственно, asyncio и проектировали.
Антон Барышев, я бы рекомендовал всё же попробовать освоить автозагрузку в X. В частности, можно сделать сессию (альтернативно GNOME, KDE, XFCE итд), которая будет запускать одно только это приложение, в том числе на весь экран. Ещё вот тут пишут, что Avalonia умеет во framebuffer, это может быть интересно с точки зрения экономии памяти, но насколько хорошо работает fb я не знаю, возможно не самым эффективным способом, тем более fb на rpi.
Василий Банников, по умолчанию в X включён xauth, который не позволяет работать с сокетом X-сервера прямым коннектом без авторизации. Нужно или авторизацию выключать, или разбираться, как получить доступ к ключу (честно говоря, не изучал, как это работает и насколько хорошо защищено).
YOKARAMANE, в чём глубокий смысл global в этих функциях?
В этом коде обработчик реагирует только на текст "text" (выводит сообщение и в переменную text записывает id сообщения) и на "s" (выводит сообщение, а потом регистрирует следующий обработчик). Думаю, планировалось не это, правда?
Asriel, не думаю что есть готовый, хотя если найти полностью работающий метод скачивания оттуда файлов, то написать такого бота несложно. Но, опять же, для разовой задачи проще скачать и выложить руками, чем воевать с написанием работоспособного бота.
Asriel, это довольно странное условие, и да, реально такой бот, сделанный не для мелких личных нужд, долго не проживёт, так как яндексу это не может понравиться.
Треды в питоне не шибко удобные, так что тут хороший повод использовать вебхуки. Можно немного доработать стандартный пример https://github.com/eternnoir/pyTelegramBotAPI/blob...
Например, сделать bot1, bot2, сделать два app.route с токенами обоих ботов, сделать два вызова set_webhook. Тогда каждый бот будет получать запросы на свой адрес и независимо от другого обрабатывать.
Если надо совсем настраиваемо на произвольное число ботов, то придётся отказаться от декораторов и явно регистрировать обработчики для каждого бота. Сделать app.route, в котором по токену находить в словаре инстанс телебота, от которого вызывать process_new_updates.