shurshur

Здесь много неправильно, и не странно, что это не работает.

На первом уровне вложенности основной код, который должен делать 3 вещи:

1. Импортировать модули.

2. Создавать объект класса TeleBot.

3. Вызывать от него polling.

Что делает polling? Это цикл, который дёргает у Bot API метод getUpdates и получает время от времени новые обновления от Telegram. Для каждого он вызывает обработчики (handler). По умолчанию нет ни одного handler, и простейший бот без них не делает ничего - только скачивает и сразу выбрасывает получаемые сообщения.

Далее надо сделать обработчики. Они представляют из себя обычные функции. Например, обработчик сообщения принимает объект класса Message, в котором все данные по сообщению: отправитель, текст, время отправки, id чата итд.

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

@bot.message_handler(commands=['start','menu'])
def start_message(message):
  # в этом обработчике мы можем обработать команду /start или /menu,
  # при этом можно брать из message данные о сообщении:
  # message.text - текст
  # message.from_user - объект класса User с данными отправителя
  # message.chat - объект класса Chat с данными о чате (группа или приват)
  ... тут нужные действия ...

Использовать декоратор без @ и последующего описания функции бессмысленно - он просто ничего не будет делать (потому что декоратор - это специально устроенный класс, вызов bot.message_handler создаёт экземпляр этого класса, от которого потом вызывается специальный метод, а тут этого не происходит).

Вызывать на первом уровне вложенности bot.send_message таки возможно, но... но тут в него передаётся, например, message.chat.id - а что такое message? Этой переменной в скрипте нет. И откуда бы она взялась, если сообщение получается внутри вызова bot.polling и должно передаваться обработчику, который нужно было бы оформить как функцию с декоратором? В коде нет ни одного такого. Да и переменная message будет актуальна только внутри этого обработчика, снаружи функции она не будет доступна.

В общем, это никак не может работать.

Плохая идея начинать изучения языка с ботов, области, в которой уже нужно обладать определённым уровнем познаний. Начинать имеет смысл с азов. Делать сначала простейшие задания (вида "попросить пользователя ввести два числа и вывести их сумму"), освоить циклы и функции, работу с файлами и строками, ну и всё такое. Затем, вернувшись к теме ботов, уже будешь делать всё не вслепую, а хоть как-то понимая происходящее.

Представь себе, что ты бы купил автомобиль, и не смог бы понять, как его завести. Начал бы тыкать куда попало. Например, нашёл нипель на колесе - подёргал. Дворник крутится, если приложить усилия (ой, сломал, теперь не будет ездить?). Сзади труба торчил - к ней надо водопроводный шланг подвести? Вот примерно так сейчас ты делаешь бота. Даже если тебе подскажут, что изменить, ты всё равно не научишься программировать и не будешь понимать, что сделал.

И не будет работать, так как URI передаётся только после установки соединения, на момент установки соединения ещё нельзя идентифицировать, куда перенаправить трафик. Для решения этой задачи надо использовать reverse proxy, в качестве которого популярно использовать nginx. Но так как тут не нужно раскидывать по нескольким разным серверам, то проще просто в целевом web-сервере отвергать запросы, не подходящие под условие. Если это почему-то невозможно (например, сервер является чужим приложением, в котором нельзя ничего изменить), то можно поставить nginx в разрез.

https://www.jamendo.com/
https://developer.jamendo.com/v3.0
Довольно много музыки (в том числе очень неплохой) на либеральных лицензиях. Но исполнители преимущественно малоизвестные.

Банковскую карту может выпустить только банк с аккредитацией PCI DSS. Очевидно, что криптовалютные сервисы не могут такого предоставить. Также, платёжные операции в карточных системах выполняются в конкретных валютах (рубли/евро/доллары/тенге/лиры/юани/итд), поэтому банк, который бы согласился рисковать играми в криптовалюту, фактически бы всё равно имел бы для клиента настоящий денежный счёт и конвертировал бы в него криптовалюту по своему собственному курсу (скорее всего, с явной невыгодой для клиента для покрытия рисков и неудобств от волатильности криптовалют).

Рекоммендую отказаться от discord_slash и перейти на потомков discord.py 2.0 (который так и остался в alpha и в pypi не опубликован) в виде форков discord.py, в которых slash commands работают из коробки. Мои эксперименты показали, что discord_slash ломает часть функциональности discord.py, и разбираться, что там пошло не так, я посчитал малоосмысленным. Я протестировал pycord, nextcord и disnake и остановился на последнем как наиболее развитом (по состоянию на декабрь было именно так), но свой выбор не навязываю.

Нужно будет всего лишь заменить декоратор @bot.command на @bot.slash_command, очень удобно и никакого мазохизма.

Если надо определять язык текста, то смотреть в сторону language identification, например, есть библиотека fasttext, и вот есть первый попавшийся пример реализации на js https://github.com/rse/fasttext-lid (но в гугле я видел и другие, не знаю, какая будет лучше).

Если надо определять язык конкретных слов, то может быть интересно использовать стеммеры под нужные языки и затем проверять наличие слова в словаре для этого языка. Либо перебирать весь словарь с учётом расстояния Левенштейна либо другой текстовой метрики.

В общем, это не самая тривиальная задача.

Я пришлю тебе

'';drop table config;select bitcoin from config

И таблица config будет удалена. Это называется SQL-инъекцией.

Ты не оборачиваешь строку в кавычки, разумеется, ничего хорошего не получится. В случае цифр, конечно, запрос без кавычек выполняется успешно. Но вообще это неправильный способ использования SQL, так как любая кавычка его сломает, а тщательно подготовленный текст (пример я привёл) вообще вызовет не тот запрос, который планировался.

Правильно использовать плейсхолдеры:

q.execute("UPDATE config SET bitcoin=? WHERE id=?", (new_bitcoin, user_id))

В этом случае база данных сама правильно всё подставит и выполнит.

Если у бота включена опция Group Privacy, то он не видит сообщений в ней. Её надо выключить.

BotFather - Bot Settings - Group Privacy.

upd: Хотя, конечно, дело в другом, речь идёт о каналах, каналы - это не группы, там другой метод обработки сообщений.

1. Очень сильно зависит от задачи. Конечно, если точно не понимаешь, зачем это тебе нужно, то имеет смысл доверить настройку сети докеру. Но если надо, чтобы вместо bridge был macvlan со строго заданной сетью и конкретным parent-интерфейсом, то этим нас докер сам не обеспечит, если ему не подсказать.

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

3. Это попытка бороться с довольно типичным подходом начинающих докероводов, которые обходятся "универсальным" контейнером, исполняющим любой php-код с внешнего каталога. Конечно, для быстрых экспериментов "ща я чёта сваяю и запущу для проверки" это даже не очень плохое решение, но при широком использовании такого подхода смысл докера существенно уходит: вместо готового к разворачиванию приложения мы имеем контейнер, который ничего не умеет и которому приходится самостоятельно пилить отдельную систему доставки самого кода. Вместо этого лучше сразу научиться и отладиться готовить полноценный образ. В конце концов, можно все приложения делать потомками этого супер-образа с php, что сделает их сборку довольно быстрой.

4. Относительные пути - это как раз очень удобно для многих задач. Мы имеем каталог с проектом, в котором docker-compose.yml и все нужные данные. Размещение данных предсказуемо, точно видно, кто их использует, какой у них размер и всё такое. Удобно в случае чего перекидывать между серверами вместе с данными: просто погасил, rsync, запустил. Напротив, хранение данных в анонимных томах в /var/lib/docker с непонятными именами - это часто антипаттерн, при котором ценное место в /var заполняется чем-то непонятным, что толком невозможно идентифицировать. А использование имён может привести к той же проблеме, что и container_name - в разных compose-проектах имена пересекутся, и узнаешь это только тогда, когда уже сломается.

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

Нет, на номера Twilio шлют смс вовсе не операторы. Приложения и сервисы не используют сети операторов для доставки. A2P (application-to-person) SMS работают не так. Для этого используются специальные интеграции, промышленным стандартом здесь является протокол SMPP. Как правило, конкретный сервис пользуется услугами некоторого поставщика-агрегатора, в которого может посылать не только посредством SMPP, но и каких-то других протоколов. Но в дальнейшем агрегатор пошлёт уже по SMPP либо конечному оператору, либо другому посреднику. Интегрироваться напрямую со всеми операторами мира попросту нереально, их в России десятки, в США сотни, а сколько в целом по миру уже невозможно посчитать. При этом нельзя никогда узнать, пойдёт ли SMS из конкретного агрегатора напрямую конечному оператору или другому посреднику (и в целом невозомжно узнать, сколько посредников вообще будет по дороге). На любой стадии цепочки может что-нибудь глючить или работать недостаточно достоверно.

Кроме того, любая стадия цепочки может что-то зарезать по своему усмотрению: по текстам, по номерам, по источнику трафика (с каким system_id поступило сообщение). В конце концов, во многих странах весьма сложные правила и технические условия. Например, в Индии максимальная длина альфанумерического имени 6 символов, а в России 11, во многих странах или у отдельных операторов имена должны предварительно регистрироваться (могут быть платны или бесплатны, могут требовать или не требовать документальных подтверждений на товарный знак). В некоторых странах мобильные сети в принципе не поддерживают альфанумерические имена (например, в США), и там необходимо делать подмену на цифровое, которое в дальнейшем не всякий оператор пропустит.

До кучи, некоторые номерные ёмкости могут намеренно блокироваться, как используемые для целевой регистрации аккаунтов без наличия физической сим-карты. Например, на некоторые сервисы аренды номеров WhatsApp принципиально не отправляет SMS, даже если соответствующий номер никогда не использовался.

Ссылаться на успешное хождение SMS между обычными абонентскими устройствами нельзя, так как обычные SMS могут ходить по SS7, что для A2P SMS вообще невозможно. Даже если найти за деньги или в даркнете дырку в сеть SS7 у какого-нить африканского оператора, то доставки не будет вообще или её качество будет ужасным (насколько помню, для России лет 5 назад доставка не превышала 40%, сейчас скорее всего ещё хуже).

С вопросами о неработе следует обращаться в техподдержку конкретного сервиса. Пусть они пушат своего поставщика, а тот по цепочке добивается у своих партнёров.