Web-приложения на Flask: как бороться с циклическими импортами

[AlexBin]

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

[Andy_U]

А вот сюда посмотрите.

[AlexBin]

А вот сюда посмотрите.

Не знаю как вас отблагодарить за ссылку. Плюсану карму.

[Andy_U]

del.

[Tishka17]

Какой-то плохой DI получился. На глобальных переменных. В итоге в сам работщий эземпляр вьюхи мы ничего и не инжектируем. Не понимаю, чем вам не угодили обычные class-based views с пробросом зависимости через __init__.

[SSul]

Это не совсем так. В подобных решениях в файле app.py можно указать переменные, которые будут использованы позже и связаны с каким-либо эндпоинтом через наследник класса di_cnt.DeclarativeContainer, который не является глобальной переменной из арр.ру.

[Tishka17]

Я не использовал никогда эту библиотеку и не знаю её возможностей, сужу по примеру. Я всегда считал, что DI — это когда зависимость передается в конкретный экземпляр объекта. Классически это делается через поля или параметры инита. В вашем случае зависмостью вьюхи является глобальная переменная DIServices определенная на уровне модуля. То, что она заполняется данным отложенно и из другого модуля, не делает её менее глобальной.

Фактически в случае нормального DI предполагается, что можно сделать несколько экземпляров вьюхи и передать туда разные зависимости, не меняя её кода. В вашем примере это невозможно. Более того, я не понимаю, зачем для такого примера тащить целую библиотеку, а не просто сделать класс такого вида:

class DIServices(di_cnt.DeclarativeContainer):
    mail: Optional[Email] = None

[Tishka17]

Прошу прощения, поторопился с кодом. Я имел ввиду вот такой тривиальный

class DIServices:
    mail: Optional[Mail] = None

[SSul]

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

[Tishka17]

В таком случае хочу как обычно предостеречь всех пользователей DI-контейнеров (aka DI-фреймворков): неосторожное их использование приводит к потере DI не смотря на название

[SSul]

Спасибо)