Vindicar

1. Встраивают интерпретатор нужного языка, при необходимости урезают стандартную библиотеку (чтобы не давать коду плагинов лишних возможностей) и подсовывают туда средства общения с хост-программой.
2. Если нет нужды изолировать плагин от остальной программы, то полагаю что да, накладные расходы на поддержку плагинов уменьшатся в случае, когда плагин написан на том же языке, что и программа. В противном случае организация "песочницы" может занять столько же усилий, сколько встраивание интерпретатора.
3. Лучше, если язык плагина является или интерпретируемым (как Lua или JS), или компилируется в байткод (как Python/Java/C#). Также желательно, чтобы язык плагина имел средства интроспекции.

Пусть 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.

Распарси скобки в выводе корректно, и загадка исчезнет.

<\bound method Aliases.new_alias of 
    <\aliases.py.Aliases object at 0x7fcf55c104c0>
>

Два разных метода одного объекта (с одним адресом).

И да, имей ввиду, что если ты берешь адрес метода на экземпляре объекта - ты получаешь не адрес функции в классе, а адрес специального объекта-обёртки bound method, который эту функцию привязывает к конкретному экземпляру класса. Иными словами:

import inspect

class A:
    def test(self, x):
        print(x)

a = A()
print(A.test)  # <function A.test at 0x0000029692C0FB50>
print(a.test)  # <bound method A.test of <__main__.A object at 0x0000029692BF3040>>
print(inspect.signature(A.test))  # <Signature (self, x)>
print(inspect.signature(a.test))  # <Signature (x)> так как значение self зафиксировано - это a
# причём обёртка создаётся каждый раз новая, это НЕ один и тот же объект
print(a.test is a.test)  # False
# но две обёртки одного метода равны.
print(a.test == a.test)  # True
# а метод класса всегда один и тот же
print(A.test is A.test)  # True
print(A.test == A.test)  # True

Достаточно включить голову. У тебя написано
x = phonenumbers.parse(self.ent_1, 'None')
В то же время ниже:
self.ent_1 = Entry(self,width=36)
Я очень сомневаюсь, что метод parse() принимает первым параметром поле ввода. Скорее, ему нужна строка, т.е. содержимое поля ввода. Как извлечь содержимое поля ввода, можно нагуглить. Подсказка: у поля ввода есть метод get().

Вообще в коде много странного. Например,
carrier_2 = print(carrier_1)
carrier_2 всегда будет None, так как print() выводит текст в консоль и возвращает None.
Что ты тут пытался сделать?