Vindicar

class Interface:
    a = 1
    b = dict()
    c = []

Ты описал класс с тремя атрибутами класса. Не экземпляра, а именно класса.
Три атрибута экземпляра описываются как

class Interface:
    def __init__(self):
        self.a = 1
        self.b = dict()
        self.c = []

А если тебе нужен эквивалент интерфейсов, почитай про typing.Protocol.

А всего-то нужно прочитать документацию. Там этот случай описан, и показано, как делать правильно.

con = sqlite3.connect(":memory:")
cur = con.execute("CREATE TABLE lang(name, first_appeared)")

# This is the named style used with executemany():
data = (
    {"name": "C", "year": 1972},
    {"name": "Fortran", "year": 1957},
    {"name": "Python", "year": 1991},
    {"name": "Go", "year": 2009},
)
cur.executemany("INSERT INTO lang VALUES(:name, :year)", data)

# This is the qmark style used in a SELECT query:
params = (1972,)
cur.execute("SELECT * FROM lang WHERE first_appeared = ?", params)
print(cur.fetchall())

Открой для себя функции zip() и itertools.zip_longest().

Нет. Ты можешь открыть файл на чтение и запись, и затем скакать по файлу с помощью seek(), но это ничуть не быстрее. Меньше дискового пространства требует, вот и вся выгода.
Текстовые файлы вообще плохо поддаются частичному обновлению.
Если тебе такое требуется часто, впору смотреть в сторону простых БД, вроде sqlite. Ей не требуется отдельное серверное ПО, и база данных будет состоять из одного файла. Вполне себе нормальный апгрейд.

Включи логику.
Чтобы прочитать/записать элемент списка, нужно знать его индекс.
Ты знаешь значение минимума/максимума, но не индекс.
Вывод: нужно в цикле поиска обновления не только само значение minimum и maximum, но и в отдельной паре переменных хранить индекс i, где был обнаружен последний минимум/максимум.

Любопытно, что ты уже используешь enumerate() для перечисления списка, но до сих пор не использовал индекс очередного элемента i, который он тебе сообщает.

Ты хочешь странного. Но ты можешь сделать класс-посредник, который будет дружественным к "владельцу" (основному классу), и будет предоставлять доступ к защищенным методам владельца. А в остальные функции уже передавать этого посредника. Этакий Public Морозов.

Но лучше еще раз подумать, зачем тебе доступ к защищенному контенту класса вне этого класса. Или доступ не нужен, или контент не должен быть защищённым.

А сложность начинается, как только задачи, стоящие перед ботом, перерастают уровень примера в документации видеотуториале пятилетней давности.

Нужно сделать несколько под-команд у команды. Напишу цепочку if-elif-else, делов то. Ой, а теперь простыня кода на пять экранов, в которой фиг чего найдёшь. Потому что нет привычки структурировать код.

Нужно, чтобы несколько команд/событий формировали цепочку (сценарий). Например, пользователь отправил тре сообщения, первое с именем, второе с возрастом, третье с адресом. Ой, а как это сделать вообще? Не зная понятия "конечный автомат" (finite state machine, FSM), очень трудно догадаться, как тут поступить.

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

Нужно, чтобы бот выполнил длительную задачу, и написал сообщение, когда она выполнится. Не вопрос, напишу функцию, вызову её, а сразу после отправлю сообщение. Ой, а бот не отвечает! Потому что рабочий цикл asyncio занят этой длительной операцией и не может отреагировать на поступающие данные. Нужно иметь хорошее представление о том, как работает асинхронная программа.

Нужно добавить боту графический интерфейс - админку. Ой, а работает или интерфейс, или сам бот! Потому что нужно представлять, как устроено большинство GUI-фреймворков, и как устроена асинхронное приложение. А заодно понимать многопоточность, вопросы синхронизации действий между двумя потоками, и особенности работы с asyncio в многопоточных приложениях. Потому что одним потоком тут обойтись будет очень непросто.

Нужно хранить данные в БД. Ой, а почему у меня проблемы при записи в БД имени пользователя? А потому что погромист собирает SQL-запрос через форматирование строк. Надо было почитать доки, чтобы наткнуться на prepared statements, они же parameterized queries.

Нужно хранить данные в БД. Вот только данные имеют связи многие-ко-многим. Я знаю! Я буду просто добавлять или удалять столбцы в таблицу! Потому что не освоены даже азы проектирования БД. Тут уже nuff said. И да, я такое видел на этом сайте.

Незнание средств языка и основных приемов построения алгоритмов и структур данных приводит к диким велосипедам, которые создают больше проблем, чем пользы. Особенно если к этому добавляется нежелание находить и читать документацию на фреймворк, на котором построен бот.