shurshur

И в чат так же можно, если у бота есть доступ к написанию сообщений в группу и в качестве chat_id передан правильный id чата.

А почему name в запросе идёт первым, а user_id - вторым - при этом в передаваемых параметрах наоборот?

cursor.execute("UPDATE gaming SET name =  ? WHERE user_id = ?", [user_id, text])

Нет, невозможно через Bot API получить информацию по ранее отправленным сообщениям. Следовало сохранять эти сообщения или исходную информацию, на которой они были основаны.

В этом примере бот получает сообщение с ТЕКСТОМ /delete, пытается найти в нём forward_from_message_id (откуда???) и удалить в чате с пользователем-отправителем сообщение с таким id. Довольно очевидно, что это работать не будет вообще никак.

Какая вообще задача стояла?

Это меняется в свойствах бота у BotFather.

Для Basic Auth:

from requests.auth import HTTPBasicAuth

r = requests.get(url, auth=HTTPBasicAuth(login, password))

Для других способов авторизации можно написать свой класс. Например, для Bearer:

class BearerAuth(requests.auth.AuthBase):
  def __init__(self, token):
    self.token = token
  def __call__(self, r):
    r.headers["authorization"] = "Bearer " + self.token
    return r

r = requests.get(url, auth=BearerAuth(my_token))

Ох, ну тут всё неправильно.

Не надо пихать ещё одну функцию send_message внутри send_message. Их надо вынести на один уровень. И вообще, назвать более адекватно их содержанию. Ведь первая обрабатывает команду /weather, а вторая - название города. Странно называть их одинаково неопределённым send_message (чтоб враги не догадались?).

Что происходит в этом коде? Сначала мы регистрируем обработчики команд /weather и /start с помощью декоратора. При вызове /weather мы КАЖДЫЙ раз (ведь это часть функции-обработчика на следующем уровне вложенности!) заново определяем обработчик для content_type=text. Далее после первого вызова /weather этот обработчик начинает работать на все текстовые сообщения. Причём на сообщения ВСЕХ пользователей нашего бота. То есть реально, один вызывает /weather и тем самым изменяет поведение бота для всех пользователей сразу. Если в боте будет где-то ещё определяться таким же "внутренним" описанием ещё один обработчик content_type=text, то он будет всегда игнорироваться до следующего перезапуска бота, ведь один обработчик текстовых сообщений уже есть и он всегда будет применяться.

Чего удивительного в том, что бот работает ровно так же странно, как странно написано в его коде?

Надо понимать, что обработчик сообщения принимает ОДНО сообщение и его обрабатывает. Он не может принять сообщение и ещё сразу же следующее. Каждое обработается своим обработчиком. Чтобы обработка сообщений зависела от ряда сообщений, используют FSM (Finite State Machine), машину состояний. В telebot есть довольно простая в использовании FSM на основе вызова register_next_step_handler. Вызов register_next_step_handler переопределяет то, каким обработчиком будет обработано следующее сообщение с этим пользователем (точнее, в этом chat_id, который может быть и идентификатором группы).

Собственно, принцип работы такой: когда пользователь вызывает /weather, мы должны с помощью вызова bot.register_next_step_handler зарегистрировать кастомный обработчик следующего сообщения. Этот обработчик будет обрабатывать только сообщения этого пользователя, подобное поведение не будет влиять на других пользователей. Для более сложных взаимодействий можно делать длинные и даже ветвящиеся цепочки обработчиков, спрашивать у пользователя разные данные, предлагать изменить ранее введённые данные итд итп.

Официальный пример использования смотреть тут.

Нужно вместо while True гонять цикл по какому-то другому условию, которое рано или поздно изменится. Например, можно завести глобальную переменную, задавать ей True в команде запуска, а в команде остановки выставлять False. Да, это очень дурацкое решение, так как нельзя будет использовать команду в разных каналах одновременно. Но как бы и задача сама по себе очень дурацкая, явно попытка научиться делать ну хоть что-нибудь...

Обычно если нужно делать какие-то регулярные задачи для бота, применяют другие решения. Например, расширение tasks или модуль aioschedule. Длинный цикл в обработчике команды - это часто не очень хорошее решение. Например, если бот будет перезапущен, цикл не будет запущен заново, а если задачи цикла хранятся в сохраняемой между перезапусками очереди - то перезапуск бота не будет влиять на этот функционал.

Вообще говоря, в данном случае скачать совсем не проблема безо всяких скриптов, достаточно wget:

wget -r -np https://codernet.ru/media/

Так, как написано сейчас, работать не будет. Потому что регистрируется несколько обработчиков с одинаковым условием content_types=text, и применяется только первый. Надо как раз использовать bot.register_next_step_handler (или городить свой велосипед на замену). Смысл обработчиков именно в том, что они получают сообщение, обрабатывают его и завершаются. Ждать следующего сообщения не нужно.

И зачем вообще внутри одной функции описывать другую? Так иногда делают, но в данном случае это не имеет смысла.

А что делает message_text у InlineQueryResultArticle? Это параметр конструктора InputTextMessageContent. Неудивительно, что ругается.