Vindicar

Читаем доки telebot.
https://docs.python-telegram-bot.org/en/stable/tel...

message (telegram.MaybeInaccessibleMessage, optional) - Message sent by the bot with the callback button that originated the query

Выделение моё. Теперь понятно, почему ты получаешь id самого бота?
А если чуть выше глянуть, там ещё интереснее.

from_user (telegram.User) – Sender.

Привыкай находить и читать документацию, там много интересного.

Тебе нужно повторять ввод аргументов, пока пользователь не введёт их правильно? Ну вот и повод почитать про циклы.

while True:  # бесконечный цикл
  x_str = input('Введите x:')  # вводим число
  try:  # внутри блока try мы будем отлавливать ошибки - исключения
    x = float(x_str)  # пробуем преобразовать строку в число
  except ValueError:  # в случае чего float() выкинет исключение ValueError
    print(x_str, 'это не число. Попробуйте ещё раз.')  # сообщаем пользователю
  else:  # если ошибки не было
    break  #  то прерываем цикл, у нас в x лежит нужное значение
  # мы делаем break только в ветке else - значит, пока отрабатывает ветка except, цикл продолжится

В принципе, если тебе нужна только одна попытка, ты можешь вытащить блок try-except из цикла, убрать ветку else, и заменить ветку except на что-то типа:

except ValueError:
  print(x_str, 'это не число. У вас есть ещё одна попытка')  # сообщаем пользователю
  x_str = input('Введите x: ')
  x = float(x_str)

Тогда получится обойтись без циклов.

Но без try-except обойтись сложнее. Да, ты можешь предварительно проверить строку на соответствие шаблону десятичного дробного числа, но честно? try-except куда проще, так что стоит его освоить. Главное - не "глотай" ошибки, реагируй на них.

Общая идея задачи. как я её понял: дрон с воздуха снимает лабиринт, затем алгоритм сшивает кадры в одно изображение, извлекает форму лабиринта и строит путь по нему. Так? Если так, это должно было быть в вопросе.

У тебя три чётко видимых шага.
1. Сборка карты лабиринта по видео с дрона. Я бы для начала использовал поиск локальных особенностей (SIFT, углы по Харрису, или что-то столь же простое).

Они обычно не позволяют работать в реальном времени, но это для задачи и не требуется. Затем, зная позиции особенностей на каждом изображении, сравниваем их с "соседними" изображениями.

По итогам сравнения мы получим проективное преобразование, описывающее, как надо повернуть/наклонить/растянуть/etc один кадр, чтобы совпали общие с соседним кадром части. Подвергнув кадр такому преобразованию, мы сможем все кадры привести к одной плоскости.

Тогда постепенно построите одно изображение-карту, а уж дальше его можно будет обрабатывать обычными средствами. Там, пороговое преобразование или что для выделения "стен", определение границ лабиринта, и дальше уже тупой flood-fill для поиска пути.

Читаем и осознаём текст ошибки. UnicodeDecodeError - ошибка декодирования строки байт в юникод-строку, т.е. косяк с кодировками. В списке traceback ищем последний элемент, который ссылается на твой код.

File "C:\Users\Maks\PycharmProjects\pythonProject7\main.py", line 57, in check_news_update
    news_dict = json.load(file)

Т.е. косяк при чтении json из файла. При вызове load() кодировку нельзя указать, так что проверяем, откуда приходит файл.

with open('news_dict.json') as file:  # где encoding? где режим открытия?
        news_dict = json.load(file)

Вот и ошибка - не указана кодировка (и я бы явно указал режим открытия 'rt'). Причём при сохранении не забыл ведь указать...

with open("news_dict.json", "w",encoding="utf-8") as file:  # а тут всё правильно
            json.dump(news_dict, file, indent=4, ensure_ascii=False)

А доки на телебот читать пробовал? Нет? Ну так попробуй, там много интересного.

send_message(...)
reply_markup (telebot.types.InlineKeyboardMarkup or telebot.types.ReplyKeyboardMarkup or telebot.types.ReplyKeyboardRemove or telebot.types.ForceReply) – Additional interface options. A JSON-serialized object for an inline keyboard, custom reply keyboard, instructions to remove reply keyboard or to force a reply from the user.

Выделение моё.
Т.е. вместо клавиатуры передаёшь специальный объект. А дальше тыкаешь по ссылке ForceReply и смотришь что это за объект и как его сконструировать.

Во-первых, нужно чётко описать цепочку трафика. Вот первый вариант:

[клиент] --> [решающий прокси] --> [реальный прокси] --> [целевой сайт]
                     \--> [другие сайты]

Т.е. клиент всегда ходит через решающий прокси (тот, который принимает решение, как обращаться к сайту), а далее трафик идёт по одной из двух веток.
Плюсы: у клиента фиксированная конфигурация, требуется только поддержка прокси, не требуется доп. ПО на кленте
Минусы: решающий прокси тащит на себе весь трафик клиента.

Если это недопустимо, т.е. тебе позарез нужно что-то такое:

[клиент] --> [решающий прокси] --> [реальный прокси] --> [целевой сайт]
    \--> [другие сайты]

То решение нужно принимать на стороне клиента. Тут есть два варианта.
Вариант А: решающий прокси разворачивается на клиенте. Так работает nekoray, например.

[клиент --> решающий прокси] --> [реальный прокси] --> [целевой сайт]
                     \--> [другие сайты]

Плюсы: ПО на клиенте всё ещё требует только поддержку прокси, и всё.
Минусы: на клиенте ставится доп. ПО, управление производится на машине клиента (неудобно если их несколько)

Вариант Б, которым я сам пользуюсь: использовать PAC-файл. Он выполняется в контексте браузера и содержит логику на JS, которая определяет, как посылать каждый запрос. Разумеется, генератор и прокси могут быть на одном узле.

[Генератор и хостинг для PAC-файла]
   ^
   |
[клиентский браузер] --> [реальный прокси] --> [целевой сайт]
    \--> [другие сайты]

Плюсы: на клиенте фиксированная конфигурация и нет доп. ПО. Все решения принимаются сервером, который периодиченки обновляет PAC-файл.
Минусы: работает ТОЛЬКО с браузером, если прокси недоступен, браузер может начать пытаться слать запросы напрямую. Трудно повлиять на то, как часто клиент будет перезагружать PAC-файл.

Вариант В: использовать маршрутизацию совместно VPN, чтобы завернуть все пакеты на целевые хосты в VPN, и только их.
Плюсы: работает с любым ПО, даже если оно не умеет прокси.
Минусы: Требует полноценный VPN с виртуальным сетевым адаптером, а не прокси. Определить подсети по имени сайта нетривиально, ибо CDN могут менять адреса без предупреждения. Раздавать 100500 маршрутов на клиенты тоже нетривиально.

Ну так ты не озаботился изучением работы инлайн-кнопок, вот и результат.
У тебя две функции отмечены декоратором

@bot.callback_query_handler(func=lambda call: True)

Эта проблема встречается регулярно, и на этом сайте уже есть несколько вопросов по ней.
Вот один из них, с моим ответом.

Вот трудно вбить в гугл "API tiktok gift"?
Вторая же ссылка ведёт на гитхаб подходящей под описание библиотеки. А там и примеры есть...
Вторая ссылка, Карл!

Ну так голову-то включи.

for row in records:
    print("ник:", row[0])
    options=[
        discord.SelectOption(label=row[0])
     ]

Ты options перезаписывашеь каждый раз, вместо того, чтобы создать этот список перед циклом, и добавлять в него элементы.

Тебе выше правильно намекнули.
Во-первых, нужно увидеть простую вещь: дописывание нуля в конец двоичного представления - это то же, что умножение на 2. Назовём это операция А. А дописывание единицы - то же, что умножение на 2 и прибавление 1. Назовём это операция Б. Таким образом, можно избавиться от двоичной системы в задании.

Второе: операция А будет давать в результате только чётные числа, независимо от аргумента. Аналогично, операция Б будет давать только нечётные числа, независимо от аргумента.

Третье: результат как операции А, так и операции Б всегда больше аргумента. Более того, больший аргумент даёт больший результат. Это легко показать.
Пусть у нас есть число x. Результат операции A меньше, чем операции Б над тем же числом, поэтому мы должны проверить только один сценарий: когда к x применяется операция А, а к x - 1 - операция Б. Значит, x станет 2 * x, а x - 1 станет 2 * (x - 1) + 1 = 2 * x - 1. Т.е. для x - 1 результат меньше. Т.е. даже в таком, самом спорном случае, меньшее число даёт меньший результат

Четвёртое: задачу можно решать задом наперёд. У нас есть целевые числа - значит, мы должны применить к ним алгоритм наоборот, чтобы получить исходные. Это и даст нам диапазон для поиска исходных чисел.

Дальше уже проще. Смотрим на начало целевого диапазона, число 876 544. Оно чётное, значит, оно могло быть создано только операцией А. Значит, чтобы получить исходное число, нужно поделить его на 2. 876 544 / 2 = 438 272. Это число тоже чётное, оно тоже могло быть создано только операцией А. 438 272/ 2 = 219 136. Оно тоже чётное. Значит, третий раз применяем операцию А наоборот: 219 136 / 2 = 109 568. Исходя из пункта 3, можем сказать, что числа, меньше 109 568, не могут дать результат, больший или равный 876 544.

Аналогично анализируем верхнюю границу целевого диапазона.
1 234 567 899 = 2 * 617 283 949 + 1 (операция Б)
617 283 949 = 2 * 308 641 974 + 1 (операция Б)
308 641 974 = 2 * 154 320 987 (операция А)
Значит, исходное число должно быть не более 154 320 987. Вот тебе и диапазон для поиска.
А поскольку большие аргументы дают большие результаты, то это означает, что ни одно число меньше 154 320 987 не даст результат, который выйдет за верхнюю границу диапазона (1 234 567 899). Т.е. искомые числа - это весь диапазон от 109 568 до 154 320 987. Посчитать, сколько чисел в диапазоне, тривиально.