Круговые зависимости Проекты C # против пакетов Python

Question

В C # код может быть организован в несколько проектов.Скажем, у меня есть два проекта ProjectA и ProjectB.Я могу настроить ProjectB для ссылки на ProjectA.Как только я это сделаю, классы в ProjectB могут использовать классы, определенные в ProjectA.Но классы в ProjectA не могут использовать классы, определенные в ProjectB, и ProjectA также не может быть создан для ссылки на ProjectB.

Есть ли какой-нибудь эквивалент в Python?Я думаю, что пакет в Python является близким эквивалентом проекта в C #.Кажется, ничто не мешает циклическим зависимостям между пакетами в python.Я могу иметь модули в эталонных модулях PackageB в PackageA, и в то же время модули в эталонных модулях PackageA в PakcageB.Это может быстро превратиться в грязную сеть зависимостей между пакетами.

Существуют ли в python конструкции или инструменты для предотвращения циклических зависимостей, как это делают проекты в c #?

Answer 1

Ответ отрицательный: пакет A до не может обнаружить , что другой пакет B, от которого он зависит, снова импортировал A.Это связано с тем, что import не выполняет код, если цель уже была импортирована в другое место.

# A/__init__.py
from B import foo
def go(): return foo.real()

# B/foo.py
import A
def use(): return A.go()
def real(): return 42

Это прямая цикличность между модулями, а не просто пакетами, и она все еще работает: если импортирована Aво-первых, B.foo.A становится ссылкой на неполное A (без go), но это не имеет значения, пока не будет вызван use.Эта неполная ссылка создается без какого-либо уведомления или проверки A.

Answer 2

Python допускает циклические зависимости, но очень редко это полезно.

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

moduleB.py

from moduleA import B

class C:
    # definition
B.start()

moduleA.py

from moduleB import C

class B:
    @staticmethod
    def start():
# remaining definitions
d = C()

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

Если packageA.moduleA импортирует что-тоиз packageB.moduleA, и packageB.moduleB импортирует из packageA.moduleA, что разрешено.