Это не выглядит как проблема systemd, сам бот аварийно завершается.
Если запустить бота вручную, от того же пользователя, с теми же параметрами, из того же каталога - работает?
Ну учитывая что средствами одного дискорда это сделать нельзя (иначе ботов не писали бы)... не всё ли равно? К тому же я дал ссылку на одно из готовыъ решений.
А точно от вашего лица? Если кликнуть по имени автора сообщения, то во всплывашке был логин и id от вашей учётки, или посторонней?
Потому что проще всего - посмотреть у кого права owner на сервер, дождаться, пока он уйдёт оффлайн, а потом сменить ник и аватарку на такую же и уже тогда писать.
Учите основы асинхронного программирования в целом.
Это не такая штука, которую можно взять и прикрутить сбоку, всю программу придётся проектировать исходя из асинхронного подхода.
Что имеет смысл, только если у вас в программе есть достаточно много параллельно выполняемых независимых задач, которые в основном завязаны на ввод-вывод.
Т.е., скажем, сетевой сервер так писать имеет смысл. А небольшую утилиту на одного пользователя - едва ли.
Примеры кода приводить не хочу, честно говоря. Тут пример = написать весь код.
2. Очень коротко: не используй time.sleep(delay), только await asyncio.sleep(delay).
Подлиннее: discord.py работает по асинхронной модели. Т.е. приходит событие, вызывается указанная тобой функция. Она что-то считает, затем, делает ввод/вывод - скажем, отправляет сообщение. Так вот пока сообщение отправляется, функция приостановлена, и может выполняться какая-то другая функция, для обработки другого события. И вот так функции передают друг другу управление по очереди, чтобы процессор не простаивал.
Почему это важно. Просто time.sleep() ничего об этом не знает, а потому с точки зрения discord.py твоя функция во время слипа занята чем-то важным. Соотв. управление она не отдаёт, и весь бот висит и ждёт. Нехорошо.
asyncio.sleep() знает о происходящем, и когда одна функция делает await asyncio.sleep(delay), то какая-то другая получит управление на это время.
3. Чего тут не понимать? Вместо фиксированной задержки типа await asyncio.sleep(1000)
делаешь рандомную типа
#равномерно распределённое значение от 1 до 100
delay = random.uniform(1, 100)
await asyncio.sleep(delay)
Если я правильно читаю условие:
a[k] < a[k-1] + a[k] + 1/2
т.е.
0 < a[k-1] + 1/2
a[k-1] > -1/2
Для натуральных чисел любой член последовательности будет удовлетворять этому условию.
Что-то тут не так.
было value_type = IntVar()
стало self.value_type = IntVar()
Разница видна?
Только что же переделали value_type из локальной переменной в методе-конструкторе __init__ в поле экземпляра класса. Неужели не догадаться, что нужно и везде в __init__ заменить обращения к value_type соответственно?
А переделали для того, чтобы к этой переменной можно было достучаться из других методов класса, в т.ч. из select_value_type().
Это основы ООП, чем локальная переменная отличается от поля класса и т.п.
Павел Соколов, А вот если моды, то там оператор import уже неудобен.
importlib в руки, делаем список имён модулей для импорта (да хоть список py-файлов в нужном каталоге), импортируем по одному через importlib.import_module(), складываем, скажем, в словарь {имя: объект модуля}, и дальше через этот словарь уже с модулями работаем.
Поспорю с вами. Например, коллекция в цикле foreach сигнализирует о своём завершении исключением StopIteration.
А отлов KeyError при чтении из словаря примерно так же быстр, как и другие методы.
Так что исключения в питоне вполне применимы. Да, бросать их не по делу не стоит, но если без фанатизма... мне кажется, в такой ситуации это оправданно. Сравните с asyncio.CancelledError.
В if вообще заходит? Правильный ли путь генерируется?
cwd - это не путь к скрипту, это текущий каталог (может совпадать, может отличаться).
Если нужен путь к скрипту, sys.argv[0] в помощь.
К слову, соединять пути лучше через os.path.join()
Во-первых, имеет смысл выделить команды в отдельный тип события, и парсить их из сообщений в одном месте, а не в каждом обработчике.
Во-вторых, смотря какого плана нагрузка на бота.
Если команды CPU-bound, т.е. что-то активно считают, но делают не так много ввода-вывода, то делать пул потоков или процессов (через multiprocessing), и прогонять обработчики через них.
Если команды IO-bound, т.е. в основном делают ввод вывод (http запросы, работу с диском, с базой и пр), то тогда проектировать бота асинхронным, и выполнять обработчики не один за одним, а вместе через asyncio.gather(). Не придётся париться с многопоточностью, но зато пока одна команда ждёт ввода/вывода - другие работают.
И да, 20к запросов в секунду - это очень много. Тут уже нужно как-то шардировать бота, т.е. запускать неколько ботов под одной учёткой, и работающих с одной базой.
Main PID: 16793 (code=exited, status=2)
Это не выглядит как проблема systemd, сам бот аварийно завершается.
Если запустить бота вручную, от того же пользователя, с теми же параметрами, из того же каталога - работает?