Многие думают, что групповые политики - такая мистическая универсальная хрень, которая универсальна и непреложна. Но это не так, для их поддержки конечная система должна явно иметь их поддержку. И далеко не всё можно поддержать вообще, не говоря уже о том, чтобы поддержать легко.
Например, представим себе, что есть групповая политика, запрещающая пользователю менять обоину на рабочем столе. Так вот, в Windows для этого штатный механизм явно проверяет, что обоину менять нельзя и запрещает её менять. Возможно, что при этом обои можно поменять через реестр? Не знаю, не знаю, но допускаю, что и в этом случае система следит за пользователем и не даёт ему это сделать.
Представим себе, что мы бы захотели распространять эту практику на Linux-системы. А как это сделать? Начнём с того, что в Linux существуют десятки Desktop Environment (DE), в некоторых из которых обои не предусмотрены вообще никак! А в тех, в которых предусмотрены, могут по-разному настраиваться, держать в разных местах конфиги... Плюс в Linux можно завести несколько десктопов (воркспейсов) и на каждом повесить свою обоину. Или настроить их рандомную ротацию.
До кучи, есть не только известные DE (KDE/GNOME/XFCE4/LXDE/WindowMaker итд итп) и редкоиспользуемые (типа OpenBox/E17/i3/fvwm2), никто вообще не требует использовать все компоненты одной DE одновременно. Например, в XFCE можно использовать оконный менеджер xfwm4, но оторвать и не запускать вообще его десктопную часть xfdesktop. Или вот например я исторически использую терминал Konsole от KDE, при том, что у меня XFCE.
При переходе на Linux надо не самые лютые практики винды пытаться воспроизводить, а решать задачи с учётом того, что это другая совершенно по-другому устроенная система.
дмитрий шевченко, скорее всего да. Ну, скажем так, обычным ардуиновым скетчем точно не обойтись, а писать событийную модель для ATmega, которую непонятно спаривать с другим функционалом и другой периферией, будет скорее всего чересчур долго и сложно. Вон, советуют ESP, где это уже заранее всё проделано именно с изначальным прицелом на поддержку Wi-Fi.
Основная проблема Wi-Fi в этой схеме - слишком много требуется софтверной поддержки. На компьютерах/малинках можно это поддерживать без проблем, на простейших же чипах сложно сделать WPA, обмен ключей и прочую обвязку.
Советую в доке обратить внимание на раздел 2.3, где перечислены не только поддерживаемые операционные системы, но и процессоры. Поддержки ардуиновского чипа ATmega нет. Собственно, в ардуине и операционной системы-то нет. И USB-хоста тоже нет.
rinaz22, PTR надо настраивать для того IP, с которого отправляется письмо. Если отправляется со своего сервера, то настраивать PTR-запись может только владелец автономной системы, в которую входит этот IP (некоторые хостеры позволяют это делать через веб-интерфейс, некоторые требуют обращения в поддержку). Если отправляется с серверов Яндекса, то - уверяю - Яндекс всё настроил уже давно у себя. На кого делегирована почта НА ПРИЁМ при этом неважно.
nedland, этот сайт существует для того, чтобы пользователи не только помогали друг другу, но и чтобы помогать приходящим из поиска. От безответных вопросов ничего хорошего не будет.
Смотря как напишешь. Теоретически, aiohttp может хорошо оптимизироваться за счёт асинхронности, если правильно использовать. Но если использовать неправильно и вызывать запросы в aiohttp последовательно, то за счёт более сложной магии с eventloop он потенциально потратит чуть больше миллисиекунд.
Но я бы советовал плясать с другой стороны. В чём задача? Насколько быстро надо получить результат? В целом, если там, допустим, 100 тыс. страниц (я от балды, ничего не утверждаю), то с 0.1 с на страницу выйдет три часа на "скачать всё". Так что если задача первично всё выгрузить и затем только ловить обновления, то может быть проще вообще не заморачиваться. Я неоднократно парсил всякие сайтики, и обычно меня не парило, если это работало часами и даже сутками.
А policy настроены на анонимное скачивание в этом бакете? По умолчанию S3 обычно предполагает, что только авторизованный пользователь может полуить файл.
Кустик Мей, ну, не удивлюсь, если автор какой-нить француз или итальянец?
Есть такая опенсурсная штука OCS Inventory, веб-сайт на perl с переменными и комментариями на французском, попытки разобраться в его коде весьма доставляют...
В общем, чем ещё помочь я не знаю. Если бы мне самому очень надо было и не было бы альтернатив, то я бы начал отладку самой библиотеки. Но это такое себе удовольстве и кучу времени потребует...
Кустик Мей, кстати, а точно в декораторе параметр aliase а не alias или aliases? И точно ли надо сочетать декораторы @bot.command и Андрей Ульдин.slash?
Все эти надстройки над discord.py фактически добавляют в стандартные классы библиотеки кастомные функции, которые, конечно, должны были бы всё учитывать, но не факт, что делают это хорошо и во всех нюансах. Особенно если добавить несколько таких разных обёрток, которые ещё и до кучи существование друг друга не учитывают.
Кустик Мей, ну вот можно попытаться понять, чем эти два кода отличаются. Может, разница всё же есть? Например, в одном есть discord_slash, а в другом обычные классические команды?
AlexNew22, ещё советую обратить внимание на комментарий к вопросу: pug-cli в инструкции предлагают установить глобально (с ключом -g), pug - локально для текущего проекта. Полагаю, самому проекту нужен pug, а pug-cli нужно только разработчику для разработки проекта, и в готовом проекте, вероятно, не требуется.
ch1ps01, суть в том, что если не использовать треды, то любые операции выполняются по очереди. Например, если команда /start выполняется 10 секунд, то любой нажавший /start в боте блокирует на 10 секунд любую его деятельность. В частности, второй нажавший /start пользователь будет ждать эти 10 секунд реакции бота.
В приведённом куске кода запускается бесконечный цикл while, который никогда сам не завершится и не вернёт скрипт к выполнению других частей кода.
Решения есть.
Во-первых, можно использовать треды. Тред (thread - нить) - это как будто бы отдельный процесс, но это "недопроцесс", он выполняется в контексте той же программы и имеет доступ ко всей её памяти. Если запустить бесконечный цикл в отдельном треде, то он не будет мешать основному коду программы или другим тредам выполняться. (У Python есть с тредами известная особенность, которую можно и полезно для своего развития погуглить по словам global interpreter lock, но GIL влияет в основном на вычислительные алгоритмы, а боты в основном спят в ожидании событий, на них это практически не влияет).
В результате можно вынести задачу обновления счётчиков в отдельный тред, который будет время от времени их сбрасывать.
Во-вторых, можно использовать асинхронный код. Судь асинхронщины в том, что, хоть и кажется, что там есть какие-то "треды", на самом деле программа выполняется в один поток, но когда этот поток ожидает ввода-вывода, он может переключиться на любую другую задачу, которая ожидание ввода-вывода уже завершила. Например, если у нас веб-сервер примает запросы от слушателей, обращается к базе данных и попутно получает обновления от Телеграма - то у него есть несколько видов ввода-вывода, в ожидании завершения которого он может переключаться между конкретными задачами.
(Дальше будет "в-третьих", но пока побольше про asyncio)
Кроме ввода-вывода, программа может ожидать звершения асинхронных (async def) функций. В чём суть? Если функция описана как async def func, а потом мы сделали x = func(), то программа не будет ждать завершения func() - она продолжит работать дальше. При этом в x будет лежать не готовое значение выполнения функции, а так называемый future result. Его можно как угодно передавать в другие функции, возвращать, собирать future в массивы итд итп. Но когда потребуется реальный результат, нужно будет сделать final_value_of_x = await x, и программа уснёт, пока func() не завершится.
Можно будет делать "псевдотреды": запустить в цикле несколько func(), а потом начать по очереди await на их результаты (для удобства для этого даже есть готовая функция asyncio.gather). Но, в отличие от тредов, тут переключение не может происходить когда угодно. Только в момент ввода-вывода и ожиданий (await) асинхронных функций, а точнее в момент передаи управления циклу событий (event loop).
В асинхронной программе всегда есть цикл событий. Программа разбивается на кусочки, которые выполняются из цикла событий и явно/неявно постоянно передают ему управление. Но если делать полностью синхронный код, то можно обнаружить, что переключения происходят редко и с большим опозданием.
Например, пусть есть такая функция:
async def func():
for i in range(10):
time.sleep(1)
Тут нет никаких вводов-выводов, нет явных или неявных обращений к asyncio. Поэтому как только начнётся реальное выполнение этой функции, цикл событий не будет все 10 секунд выполнения функции выполняться. Это, конечно, не дело. Поэтому у asyncio есть свой аналог sleep:
async def func():
for i in range(10):
await asyncio.sleep(1)
Функция asyncio.sleep на самом деле не спит, а сразу же возвращает управление циклу событий, позволяя в это время выполнять другие ожидающие задачи (и уж если их нет - тогда уже спать по-настоящему). Когда пройдёт указанное время, цикл событий вернёт выполнение уснувшей функции. В итоге функция будет спать, но программа продолжит выполняться.
Наконец, если вызвать asyncio.sleep(0), то программа спать не будет, но будет принудительное возвращение в цикл событий. Это используют, чтобы куски синхронного кода с долгим выполнением (например, сложные вычисления) могли иногда позволять переключаться программе в другие задачи в цикле событий. Например:
async def func():
for i in range(10):
time.sleep(1)
await asyncio.sleep(0)
Тут не будет хорошего и быстрого переключения в цикл событий, но хотя бы будут окошки между периодами сна в 1 секунду (это пример для иллюстрации, а не для подражания).
Асинхронщина очень популярна для разного рода ботов, сайтов, API-сервисов итд итп, потому что позволет довольно эффективно начать выполнять запрос другого пользователя, пока запрос предыдущего ещё не завершился. Собственно, нагруженные боты могут порой не оень справляться нагрузкой, несмотря даже на наличие свободных ресурсов, и asyncio им в этом помогает.
В-третьих, на самом деле к задаче можно подойти более творчески и вообще отказаться от каких-то там циклов! Дело в том, что реально необязательно очищать счётчики сразу как прошлё оговоренное время. Достаточно очищать их перед очередным использованием. Например, можно список из времени последних 5 сообщений каждого пользователя, а во время проверки антифлуда пробегаться по массиву и из каждого списка удалять все времена старше нужного периода (например, старше минуты). И пусть даже список будет часто содержать какое-то старьё (например, кто-то в полночь написал сообщение, а очистка его случилась в 7 утра, когда первый проснувшийся что-то написал), важно, что мы это количество используем только после очистки и всякое старьё не используем в расчёт.
Добро пожаловать в дивный новый мир :) Библиотека discord.py не развивается, застыла на версии 1.7.3, и не умеет отправлять кнопки в embed (а для отправки она должна из объекта embed сформировать json запроса к серверам Discord). У меня тоже были адовые глюки при попытке скрестить discord.py, discord_slash и discord-components. Чёта валилось в недрах, и фиг поймёшь как решать.
Что делать?
Во-первых, перейти на форки так и не выпущенного discord.py 2.0 (до сих пор доступного в авторском git), такие как disnake, nextcord, pycord (не знаю, какой сейчас лучше, по состоянию на конец прошлого года disnake был лучше всех, nextcord вполне ничего, а pycord сильно отставал по адаптации фич, но вроде как активно развивался).
Во-вторых, после первого пункта можно отказаться от discord_slash, так как новые версии библиотек поддерживают декоратор @bot.slash_command сами.
В-третьих, новые библиотеки умеют и сами поддерживать интерактивные компоненты. Как, впрочем, мог и discord.py 2.0.
Я в итоге для бота, которого писал, смог сделать и /команды, и меню с кнопками средствами только библиотеки disnake.
time.time() типа float
минус
event.timestamp типа str
Как вычитать из float строку никто не знает, и python тоже :) Потому он и жалуется.
Самое простое - это event.timestamp привести к типу float. Как приводить - советую таки разобраться самостоятельно - это вот очень тривиально. Толку писать сложных ботов без знания самых основ нет.
