shurshur

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

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

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

Никак, бот вообще не может добавлять никого, даже пользователей. Может только генерировать и посылать инвайт.

tcpdump -i ens18 -w file.pcap фильтры
tshark -r file.pcap -T fields -e ip.dst | sort | uniq

Можно сразу всё сделать wireshark'ом, но у него формат фильтров отличается.

В этом примере бот получает сообщение с ТЕКСТОМ /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. Длинный цикл в обработчике команды - это часто не очень хорошее решение. Например, если бот будет перезапущен, цикл не будет запущен заново, а если задачи цикла хранятся в сохраняемой между перезапусками очереди - то перезапуск бота не будет влиять на этот функционал.