r = requests.get(url_of_image)
image_data = r.read()
image_bytesio = io.BytesIO(image_data)
attach_image = Image.open(image_bytesio)Это какие переменные?
И под правой частью уравнений имеется в виду столбец свободных членов?
А так вообще зависит от текущей сложности и дальнейших перспектив. Сейчас я вижу, что adm это не признак админа (у которого по логике только два возможных значения "админ" и "не админ"), это скорее группа, статус, уровень или роль пользователя. Если всё идёт к тому, что нужно будет создавать другие "группы" и как-то управлять их уровнем доступа, то может быть даже смысл сразу закладывать для них отдельную таблицу, типа
groups:
- id
- level - уровень группы, чем выше, тем больше прав
- name
- role_id - соответствующая роль дискорда, которую назначать пользователям
При этом если бот будет для разных серверов предназначен, то всё ещё усложняется тем, что роли у каждого сервера свои.
Но нужно ли делать так сложно?
Класс с точки зрения синтаксиса языка вполне получится использовать как хранилище переменных (и так иногда даже делают), но это, вообще говоря, не то, для чего они задумывались.
Например, если мы в каком-то классе будем хранить db_name, db_user, db_password и обращаться из разных мест своего кода для получении информации для коннекта к базе, то это плохое решение. В итоге у нас работа с базой размазана по коду, во множестве мест делается коннект к ней, а если, например, мы захотим при коннекте к базе вызывать какой-то запрос (типа set names utf8;), то нам придётся добавлять это в куче мест.
Вместо этого мы можем сдеалать некий класс DB, который принимает параметры базы в конструкторе, а потом в self.connection записывает объект соединения, а запросы передавать в методе execute. Пример такого класса (там Oracle, да и сделано не очень хорошо, например, курсор надо для каждого запроса создавать новый, а не как сейчас сделано, но для понимания идеи сойдёт) https://pastebin.com/y2VLN8Tm
Далее, вместо того, чтобы информацию по пользователям из базы дёргать запросами в разных частях кода, можно сделать отдельный класс User, у которого конструктор умеет загружать данные из базы и записывать в поля класса. Соответственно, можно реализовать, чтобы метод save() этого класса записывал данные обратно в базу. Работа с данными пользователя станет намного нагляднее и удобнее.
Наконец, вместо того, чтобы самому строить красиво организованную работу с базой, можно просто взять готовую реализацию ORM (object-relational model), типа sqlalchemy или peewee, где уже многое сделано заранее, можно просто описать структуру своих объектов и всё остальное доверить ORM. Будет примерно как я описал выше, но намного меньше кода.
Для того и делят логику, чтобы информация о пользователях была не куча переменных из разных кусков кода, а вот такой один объект, в котором есть все данные и реализована какая-то логика. Кстати, о логике: у классов, как правило, должны быть какие-то методы, это не просто мешочек с данными, это некая логическая единица с какой-то функциональностью.
Можно посмотреть для сравнения, как всё устроено в самом discord.py: вот пользователь (User), вот сервер (Guild), вот член гильдии (Member), он же одновременно и пользователь, но не совсем, так как пользователь на каждом сервере имеет свой объект Member. Возможности и назначение каждого класса свои. Например, если нам надо послать пользователю личное сообщение, то его надо слать User, а если упомянуть его в чате конкретного сервера - то Member. И у всех этих объектов есть не только поля (переменные), но и методы (функции).