ИМХО, потоки использовать на веб-сервере, а так же какую либо обработку "тяжелых" данных не хорошая практика. Ваша реализация работает с потоками только по причине GIL, так как он блокирует использование общих ресурсов. Но ка только на вашем веб-сервере станет больше пользователей или увеличится время исполнения фоновой задачи в потоке то появятся лаги у пользователей.
Так как по сути в питоне исполняется всего один поток и если ваша задача в потоке процессорозависимая то клиенты будут долго ждать ответа от вэбсервера который в свою очередь будет ждать очереди на выполнение, а GIL не будет отпускать прошлую задачу.
В общем и целом. Запускайте ваши задачи через Фастапи + Celery. Через DI насколько я помню можно всегда дернуть коннекшен к БД, а Celery уже сама организует пулл процессов для выполнения задач.
А почему не использовать pydantic что бы как то структурировать вход и выход хотя бы от клиента. Хотя его можно и применить дальше при общении с сервисом создания. Более структурно обозначить форматы данных хотя бы для себя. У клиента понятное дело будет всегда Bad Request, но в логах появится осмысленная ошибка.
Шурик дело говорит. Можно подходы объединить. Написать асинхронную функцию получения кода страницы. И уже готовый результат распихивать по процессорам. В совокупности это даст результат.
while True:
schedule.run_pending()
bot.polling(none_stop=True)
time.sleep(1)
Тут просто уехали отступы или вот так и есть в коде? Тогда этот блок не входит в основной цикл и не будет исполнятся.
Ну и ошибка конечно не в шедулере у тебя а как минимум в foo. Ты туда аргумент не передаешь.
1) У тебя сеты по разному называются. dann и dan
2) Зачем пользовать асинхронную библиотеку когда на единственном запросе где ты мог получить прирост производительности ты используешь синхронный метод.
JaxWill, я имею ввиду если будете писать свое приложение. Полностью свое. Там уже бизнес-логику можете реализовать какую угодно. Но с помощью телеги вашей задачи не достичь к сожалению.
