utsiye, при такой постановке вопроса - да Аллах его знает...
Неизвестно, что будут делать пользователи и как часто, а также, сколько времени бот будет удовлетворять их запросы.
Например, пусть у нас 1000 пользователей, и в среднем каждый оставляет 1 сообщение в 2 дня. Тогда нагрузка 500 сообщений в сутки или 1/3 сообщения в минуту. Если запросы выполняются меньше 20 секунд, то мы уложимся. Ладно, люди ночью спят, пусть в пике будет в 3 раза больше активность, тогда надо выполнять запрос не больше 6 секунд.
Вот примерно такие прикидки и надо делать.
Большинству самописных ботов даже такая нагрузка и не снилась. Я рекомендую не париться, пока не возникнут какие-то реальные проблемы.
В каком message_handler? Который обработает следующее сообщение (не нажатие кнопки)? Очевидно, что это задача для FSM, а точнее bot.register_next_step_handler.
Задание тупое до дебильного. По логам же видно, что даже база с именем mysql сломана. В реальной жизни это автоматически означает, что базу надо переинициализировать и не выпендриваться.
Возможно на этой симке "смартфонный тариф" с запретом раздавать доступ на другие устройства, но фильтрация в Москве на нём не включена или недостаточно сильно включена по сравнению с соседней областью...
Одной задачи не хватит. Нужны десятки и даже сотни. Причём бессмысленно решать синтетические задачи. Так что совет поставить себе и часто пользоваться будет наилучшим.
AlexVWill, можно вместо email хранить от него хеш, такое вполне решается. Впрочем, многие сайты специально хранят емейл, и можно авторизоваться как по логину-паролю, так и через сторонние интеграции, если емейл совпадёт. Например, такое в браузерных игрушках распространено. Уместность подобного сильно зависит от назначения сайта и того, нужна ли почта у пользователя для его функциональности.
Но если и правда есть уникальный постоянный uid, и почта сама по себе не нужна, то помнить его конечно же лучше, чем email.
alexandrsemen4ukk, в исходных данных каждая запись это словарь, в котором несколько ключей. Я добавляю в него ключ childs, в значении которого будет храниться список дочерних элементов. В следующей строчке делается append в childs, но parent_item["childs"] должен быть создан до первого вызова этого append.
winser, это надо было смотреть на хостовой системе.
Внутри каждого контейнера есть свой личный адрес 172.17.0.x на устройстве eth0.
Работает это так. При создании контейнера создаётся virtual ethernet pair из двух интерфейсов. Один интерфейс остаётся в хостовой системе с именем навроде vethXXXXXXX, а другой перемещается в namespace контейнера и получает имя eth0. Интерфейс vethXXXXXXX добавляется в bridge docker0 (см. вывод brctl show). Каждый сетевой namespace - это как отдельное сетевое устройство со своими адресами, маршрутизацией и даже своими iptables. Таким механизмом docker делает виртуальный "провод" между основной системой и контейнером и "втыкает" его в "свитч" docker0. Естественно, основная система при обращении в сетку контейнеров будет показывать IP-адрес в сети docker0.
Если использовать кастомные сетки с bridge-сетью (в том числе через docker-compose), то имя bridge-интерфейса будет вида br-XXXXXXX, и IP-адреса тоже будут назначаться другие.
Это правильный ответ, но неправильно советовать то, что первым попалось из интернета. Никто же не ест первые попавшися ягоды в лесу? И нужно давать совет, чётко понимая, что он значит.
Всё дело в том, что нужно передавать вторым аргументом cursor.execute iterable объект (list, tuple...), а запись (x) означает x а не tuple(x). Иначе бы (1+1)*2 давало не 4, а tuple(2,2). Но есть простой способ это обойти, добавив запятую: (x,) даёт tuple(x).
Запятая, кстати, тоже синтаксическая фича против некоторого неудобства. Когда есть такая какая-нибудь запись, то очень неудобно комментировать последний элемент, если всегда нужно при этом у последнего незакомментированного убирать запятую и не забыть ненароком об этом:
Чтобы развиваться в айти, надо выбрать конкретную область. Эникейщики, умеющие настраивать принтеры или чистить вирусы - это тоже айти. Админы серверов, тестировщики, техписы, PM, техподдержка - тоже айти. Но им нужны совсем разные знания неодинакового уровня сложности.
Чтобы сдать экзамен в конкретный вуз, нужно к этому экзамену готовиться: найти список требуемых тем, примеры заданий прошлых лет, почитать справочник для поступающих в этот вуз...
