Zanak

Если у вас только один класс, то большой разницы не вижу, руками, или с помощью библиотеки.
Если у вас возможна потребность в проверке +100500 классов, тогда точно выбор за специальным инструментом, например педантик.

Основная задача __init__.py - это настройка импорта твоего пакета в основной код. Ты можешь как угодно тусовать модули и пакеты нижнего уровня и скрыть этот факт за отдачей в виде "from your_package import *" с помощью init файла.
Нет ни чего предосудительного, если в этом файле будует присутствовать код инициализации, но определенную осторожнось соблюдать следует. Например, можно, случайно, получить цикл при импорте модулей. Другой пример, мы используем модели, которые используют соединение с БД, которое открывается позже.
Опять же, возможно это только мои проблемы, я сходу не могу сказать, сколько раз выполнится код инициализации, если модуль импортируется более более 1 раза, и отработает ли ваша логика, если в одном случае это "from your_module import *", в другом "from your_module import name1, name2", а в третьем "import your_module as ym".

1. Понять, по каким данным желаем итерировать. Если по разобранным данным, то меняем parse_file/counter чтобы она возвращала результат разбора, если по результатам расчета, то создаем метод/методы, для реализации генератора/итератора.
2. Все подготовительные операции должны быть сделаны до начала возможных итераций. Как минимум - это открыть файл, как максимум - произвести предварительный расчет.
3. В случае генератора мы правим counter или result, чтобы она использовала yield current_value для отдачи вызывающей стороне текущего значения (в зависимости от того, что хотим возвращать).
4. В случае итератора реализуем __iter__ и __next__ методы, первый вернет собственно сам итератор, а второй возвращает текущее значение. За подробностями предлагаю сходить в документацию :)

Вроде ни чего не забыл. :)

Давайте, для начала, поймем ваши цели. Вы хотите создать свой API, пообщаться с существующим, или приделать свой UI для известного API?

Для создания своего API указанный инструмент, FastAPI, вполне подходит. Не все фреймворки умеют формировать/отдавать swagger спеку, но некоторые это позволяют. Собственно, для создания собственного сервиса и API, по которому он будет отдавать данные, swagger непременным условием не является. Спека для swagger пишется первой, когда у вас есть генератор, который может построить заготовку проекта на нужном вам языке. Во всех остальных случаях, она, или пишется вручную, или формируется по написанному коду, с использованием соответствующих инструментов.

Пообщаться с существующим API можно, помимо, например, Postman-а и подобных инструментов, с помощью SwaggerUI, который написан на JS и может быть размещен, например, на вашем сервере. Достаточно подсунуть ему спеку интересующего вас сервера и он, в более или менее удобной форме, позволит увидеть доступные вызовы, отправить запрос, получить ответ, ну и прочитать описание каждого вызова, если автор спеки об этом позаботился. Задача swagger - это представить машинно понятное описание api, со всеми используемыми структурами запросов и ответов, чтобы клиентский код сумел его разобрать, отправить запрос, обработать ответ, и возможно, по крайней мере теоретически, сформировать форму, чтобы пользователь мог ввести свои данные, например, для отправки их в БД. Ни для чего больше, как машинно понятное описание API swagger не предназначен.

Ну и уже должно быть понятно, что SwaggerUI не предназначен для создания собственных клиентов к API. Это скорее интерактивная документация к сервису, который описан в спеке.

В выборе средств реализации пользовательского UI вы не ограничены ни чем. Мобильное приложение, десктоп, веб с шаблонами a-la django, spa приложение, все к вашим услугам. На реализацию серверной части это ни как не завязано.

Постгри вы установили?
Обычный порт для постгри - это 5432. Когда pgadmin-у указываете localhost и этот порт соединение происходит? Для пользователя postgres с паролем, указанным при инсталяции, авторизация проходит?
Добейтесь успешного соединения с помощью psql или pgadmin, потом беритесь за питон. Будет реально быстрее, в смысле понимания, что именно не пошло.

А кодировку своих исходников указываете? Лучше скрипты держать в кодировке utf8, которая является "родной", для 3 ветки питона.
В заголовок ответа сервера с погодой можно попробовать посмотреть, какую кодировку он указывает, и попробовать перекодировать (но сначала попробуйте просто указать кодировку своих скриптов, иногда хватает этого)?

> global var
Это значит, что вы хотите использовать глобальную переменную, но это не объявление переменной как таковой. Вне функции bar вам надо объявить эту переменную, тогда в функции вы сможете ее инициализировать.

Первейший совет: воспользуйтесь поиском, в данном случае может помочь поиск по "flask debug on", или подобным критериям.
Обычно включение отладки и изучение логов помогает.
Можно попробовать посоветовать мониторить использование памяти. Не уверен на сто процентов, но в одном из проектов у меня процесс по тихому сыпался, когда утыкался в память, и оптимизация по этому поводу помогла решить проблему.
Если сервер сидит за apache/nginx, загляните в их логи, иногда бывает полезно.
Более содержательных идей вряд ли смогу предложить, не видя код.

Подозреваю, что здесь, в пункте 6.4.1 и таится ответ на ваш вопрос.