shurshur

Не массив, а list (список). Или даже dict (словарь), если хочется произвольные ключи.

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

Не надо ловить абстрактный Exception вообще никогда! Тем более игнорировать его и даже не выводить в консоль. Произошла ошибка, а какая, почему произошла - ваще непонятно.

Какие тут могут случиться ошибки? Ну, например, если в user_dict нет записи с ключом chat_id, то случится KeyError. Или если в getRegData возвращается невалидный markdown-текст, то случится ошибка ApiException.

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

До кучи, не надо вызывать постоянно bot.get_me(). Это каждый раз будет вызов API. Неужели имя бота меняется каждую минуту? Достаточно запомнить при запуске бота - и достаточно.

event_json = HttpRequest.read()

Данные в запросе имеют тип bytes, а не str.

data = json.loads(request.body.decode())

Есть целый ряд библиотек на Python с реализацией Discord API, но почти всеми никто не пользуется, за исключением одной - discord.py. Библиотека настолько хороша, что весь интернет усыпан примерами и решениями именно с её использованием, а про другие никто и не знает почти. К сожалению, автор забросил разработку по личным причинам, но есть форки, идентичные натуральным, в частности, disnake, nextcord, pycord. Но многие до сих пор пользуются оригинальной библиотекой. Для указанной в вопросе функциональности её возможностей более чем хватает, нет только поддержки новомодных slash commands, но если они понадобятся - то перейти на любой форк можно почти безболезненно, так как они полностью совместимы с оригиналом.

Раздача ролей и обработка команд на основе роли - это настолько популярный вопрос у начинающих ботописателей, что повсюду (и на этом сайте в том числе) просто море вопросов, ответов, примеров, советов итд итп по этой тематике.

И не будет работать. У тебя два обработчика с одинаковым фильтром. Использоваться будет первый, в нём обрабатывается только bts2 и bts1. Решения:

1. Или переместить содержание второго обработчика в первый.

2. Или в обработчике сделать более узкий фильтр, например:

@bot.callback_query_handler(func=lambda call: call.data.startswith('bts'))
...

@bot.callback_query_handler(func=lambda call: call.data == 'startzen')
...

cursor.execute возвращает генератор, который возвращает кортежи значений. Таким образом, в конструкции:

for i in qwe.execute(""" SELECT vk_id FROM stata """):

значением i будет не значение vk_id, а кортеж из одного значения (vk_id,).

Далее, в этом цикле делается запрос с (i,), который даёт ((vk_id,),), то есть одно значение. Кроме того, внутри итерации по курсору выполняется другой запрос с тем же курсором с затиранием внутренних данных курсора от предыдущего запроса, поэтому при заходе на вторую итерацию уже не возвращается ничего. Получается один запрос по одному vk_id. Всё работает ровно так, как написано.

Что тут можно сделать?

Вариант 1. В executemany имеет смысл передать список не из одного значения, а из множества (иначе нет смысла в executemany, проще обычный execute). Например, их можно получить путём накопления в цикле в список с последующим отдельным (вне цикла) вызовом executemany. Но если с данными запроса ничего особого делать не нужно, то и цикл тут лишний, можно получить всё сразу через fetchall().

Вариант 2. Обойтись средствами SQL. Примеры:

-- добавить всем 1
UPDATE stata SET coins = coins+1;
-- добавить удвоенный доход всем с вип-статусом, если срок его действия ещё не истёк
UPDATE stata SET coins = coins+dohod*2 WHERE vip_status=1 AND vip_status_end>=NOW();

Авторизация по логину и паролю является неподдерживаемым способом и давно работает через пень-колоду. Следует использовать OAuth2.

Вызов pidfd_open предназначен совсем для другого. Он нужен, чтобы мониторить состояние процесса с помощью операций ввода-вывода (в частности, таких, как select/poll). Для доступа к stdin/stdout/stderr процесса он не предназначен, это должны быть отдельные дескрипторы (причём разные).

Для простоых применений достаточно использовать функцию popen. Если целью является разобраться в том, как это всё работает, то рекомендую написать простейшую программу с popen, затем погонять по ней strace (с ключом -f) и понять, что скрывается под капотом. В частности, понять, зачем там будут вызовы dup, fork и exec, как переопределяется stdin/stdout/stderr и всё такое.

Лучше всего поднять домен. Можно даже на samba, не покупая WinServer (и да, AD позволит делать намного больше и намного круче, поэтому если есть возможность - ею лучше пользоваться). Пользователей заводить централизовано и обучать использованию сетевого диска для личных файлов.

Также у меня был опыт организации большого парка компьютеров в компьютерных классах для проведения олимпиад по программированию. Это очень специфическая задача разового использования системы, отличающаяся от регулярных занятий. В отличие от 90-х и нулевых, когда количество знакомых участникам сред разработки можно было пересчитать по пальцам, в наше время требуется установить десятки различных компиляторов и IDE. При этом к олимпиаде всё это должно стабильно работать. Ещё до меня просто на всех компах поставили VirtualBox с эталонным образом, который переимпортировали отдельно на каждой машине к каждой олимпиаде (весёлое занятие - бегать с пачкой флешек и везде это проделывать), но это было не слишком удобно, да и участников сбивает с толку, что надо что-то там делать в окошке виртуалки.

Я подготовил на всех машинах Linux, где у специального пользователя запускаются иксы без DE и WM с headless fullscreen VirtualBox с целевой системой из образа (Windows XP). Сам эталонный образ машины лежал на LVM, а в VirtualBox передавался снапшот LV с образом. Соответственно, перед олимпиадой все машины вместо дефолтной системы вручную загружали в Linux, с сервера скриптом выполняли (ssh с ключом) на всех машинах пересоздание снапшота, а потом можно было просто ввести имя нужного пользователя. После олимпиады снапшот можно было пересоздать, получив опять чистую эталонную систему.

До кучи, саму систему и эталонный образ я раскладывал udpcast'ом по igmp, это заметно ускорило дело, даже несмотря на неуправляемые свитчи. В первый раз всё это, конечно, потребовало кучу времени, но оно того стоило. Участники в большинстве своём даже не догадывались, что работают в виртулке :)