Vindicar

Ну для начала, неплохо бы писать в вопросе сообщение об ошибке.
Я, конечно, догадываюсь, что дело в обращении к message.reply_to_message.username, и догадываюсь, что message.reply_to_message будет иметь значение None, если сообщение не является ответом... но я могу и ошибаться.

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

Я в таких случаях создаю фабричный метод.

@dataclass
class Person:
    first_name: str
    last_name: str
    bdate: date

    @classmethod
    def make(cls, first_name: str, last_name: str, bdate: str) -> 'Person':
        _bdate = datetime.strptime(bdate, '%Y%m%d').date()
        return cls(first_name=first_name, last_name=last_name, bdate=_bdate)

data = {
    'first_name': 'Adam', 
    'last_name': 'Smith', 
    'bdate': '20220617'
}
person = Person.make(**data)

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

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

Декоратор отрабатывает при создании собственно класса. На этот момент никаких экземпляров ещё нет.
self имеет смысл только в контексте тела метода класса, но не "снаружи" методов.

Так что стоит задуматься, а что именно ты пытаешься сделать. Есть ли смысл в твоём классе-обёртке?

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

@some_decorator_with_params(params)
def some_func(...):
    ...
# это всего лишь синтаксический сахар для
def some_func(...):
    ...

decorator = some_decorator_with_params(params)
some_func = decorator(some_func)  # вызываем декоратор вручную

Ну тебе же английским по белому написали: у объекта класса ApplicationCommandInteraction нет атрибута message. Если залезть в доки, его и впрямь нет. А ты зачем-то дергаешь inter.message.author. Если тебе нужен отправитель команды, то у объекта inter есть такое поле author. Почитай по ссылке.

Упрощённый пример: что сматчит "\d+" в строке "123456"? Очевидно, всё - потому что умолчанию квантификаторы + и * жадные, т.е. пытаются сматчить как можно больше. У тебя .* - т.е. "матчи всё подряд, сколько получится", а ограничивается только тем, что "дальше должна идти запятая и пробел". Обрати внимание на ещё одну запятую с пробелом в конце твоей строки data.
Что делать?
а) сделать квантификатор не жадным: type=(.*?), Тогда он будет пытаться сматчить как можно меньше.
б) уточнить, какие именно символы могут захватываться группой type=([a-zA-Z0-9_]+),

Пусть Flask-приложение стартует первым и запускает твой worker-скрипт в отдельном процессе. Так они друг другу мешать не будут, и если твой worker вылетит, Flask выживет и сможет сообщить о случившемся (ну и перезапустить worker, если надо будет).
Вопрос тут в выборе способа обмена данными между скриптом и Flask, а также между Flask и браузером.

1. Worker -> Flask:
- запуск worker через multiprocessing, обмен данными через очередь (multiprocessing.Queue).
Плюс: возможен обмен простыми структурами данных, типа списков и кортежей.
Минус: требует переделки скрипта-worker, чтобы вместо print() он отправлял данные в Queue, да и в целом его надо будет импортировать в Flask-приложение. Что-то кроме питона той же версии так не запустишь.
- запуск worker через subprocess, обмен данными через перехват stdout.
Плюс: worker остаётся без изменений, и может быть запущен отдельно. Строго говоря, любая консольная программа, не требующая ввода, может быть так запущена.
Минус: обмен данными только как последовательность строк. Что-то другое потребует сериализации на стороне воркера, и десериализации на стороне Flask.

2. Flask -> browser:
- Самый простой и дубовый способ - long-running request.
Твой обработчик запроса на Flask запускает воркера, но не закрывает соединение, а потихоньку читает поступающие от воркера данные и отдаёт клиенту. Проблема в том, что если клиент отрубился, восстановить соединение будет нельзя.
- Чуточку более сложный - polling. Один обработчик запроса на Flask запускает воркера и всё. Другой обработчик пытается прочитать накопившиеся у воркера данные, и отдаёт их клиенту. Тогда на клиенте должен крутиться JS-скрипт, который будет периодически дергать второй обработчик. Проблема в том, что если данные от воркера долго не считываются (клиент отключился), очередь/pipe для связи между процессами переполнится, и воркер "подвиснет" на операции отдачи данных Flask. Также этот подход не будет работать с двумя и более клиентами.
- Ещё более сложный, но надёжный - buffered polling. Данные от worker помещаются в какое-то хранилище (грубо говоря, в переменную). Хранилище может хранить как полную историю вывода, так и только последний полученный блок данных - смотря что тебе интересно. Тогда Flask-приложение должно отдельным потоком забирать данные у worker, и помещать их в хранилище. Основной поток будет обслуживать запросы, и отдельный обработчик запроса будет отдавать клиенту текущее состояние хранилища (целиком или последние изменения, смотря сколько хранишь).
Плюс: такая схема будет работать при любом разумном числе клиентов, в том числе при нуле.
Минус: доступ к хранилищу нужно аккуратно синхронизировать, например, с помощью threading.Lock().

def user_exists(self, user_id):
    with self.connection:
        ...
def add_user(self, user_id):
    with self.connection:

По выходу из блока with соединение закроется. Второй блок with его уже не переоткроет.
В таких ситуациях блок with использовать не надо.

Вообще ответ зависит от конкретной задачи.
У тебя преобразование каждого кусочка идёт независимо от остальных?
Если да, то всё сильно упрощается. Опиши функцию вида:

def process_one_part(part: numpy.ndarray) -> numpy.ndarray:
    ...

Которая будет обрабатывать один фрагмент изображения.
А дальше собрать их абсолютно тривиально, точно также, как ты их резал:

# пустое изображение такого же размера, как исходное, с тремя каналами по 8 бит на канал
# если на выходе у тебя другое число каналов или тип данных, поправишь
result = numpy.zeros(image.shape[:2] + (3,), numpy.uint8)

for i in range(img_h // bl_h):
  for j in range(img_w // bl_w):
    cropped = image[i*bl_h:(i+1)* bl_h, j*bl_w:(j+1)*bl_w]
    processed = process_one_part(cropped)
    # нужно, чтобы присваиваемый фрагмент имел такой же размер, как "окно" присваивания
    result[i*bl_h:(i+1)* bl_h, j*bl_w:(j+1)*bl_w] = processed
# дальше делаешь с result что тебе нужно

Ну и да... причём тут вообще имя?

Ну для начала неплохо бы внятно описать, как задаются желаемые элементы.
Если по индексам, то да, твоё решение через __getitem__() вполне работоспособно.

import typing as t
lst = ['a', 'b', 'c', 'd', 'e']  #  не называй переменную list

def split(lst: t.List[t.Any], indices: t.Iterable[int]) -> t.Tuple[t.List[t.Any], t.List[t.Any]]:
    selected = list(map(lst.__getitem__, indices))
    remainder = list(lst)
    # удаляем с конца, чтобы еще не обработанные индексы не поехали
    # вот только с отрицательными индексами это уже не прокатит
    # их придётся самомму пересчитывать в положительные
    for i in sorted(indices, reverse=True):
        del remainder[i]
    return selected, remainder

print(split(lst, [0, 3]))  # (['a', 'd'], ['b', 'c', 'e'])

comdlg32.dll в помощь, в частности GetOpenFileNameA().
Более новые диалоги используют Component Object Model для работы. Сразу скажу, мне доводилось общаться с COM-интерфейсами на чистом ctypes, и это тот ещё гемморой.

Ты в последней строке просто вызываешь sum(), но не возвращаешь значение.
А функция, которая не возвращает значение явно, возвращает None.