System importu Pythona rozwiązuje okrężne zależności, natychmiastowo przechowując częściowo zainicjowane moduły w sys.modules przed wykonaniem ich kodu. Ten mechanizm zapobiega nieskończonej rekurencji, gdy moduł A importuje B, podczas gdy B jednocześnie importuje A, chociaż tworzy okno, w którym atrybuty mogą być niedostępne.
Fundamentalny problem wynika z modelu wykonywania Pythona, który uzupełnia przestrzenie nazw modułów sekwencyjnie podczas importu. Rozważ dwa moduły, w których module_a.py zawiera import module_b, po którym następuje def func(): pass, a module_b.py próbuje wywołać module_a.func(); wyszukiwanie atrybutu kończy się niepowodzeniem, ponieważ module_a istnieje w sys.modules, ale func nie zostało jeszcze powiązane.
# module_a.py import module_b # Wykonanie wstrzymuje się tutaj, A jest zapisane, ale puste def important_function(): return "kluczowe dane" # module_b.py import module_a # Podnosi AttributeError: moduł 'module_a' nie ma atrybutu 'important_function' result = module_a.important_function()
Rozwiązanie wymaga przekształcenia, aby wyeliminować cykle lub zastosować schematy leniwej ewaluacji. Programiści mogą przenieść importy do wewnątrz definicji funkcji, użyć importlib do dynamicznych importów lub zrefaktoryzować współdzielone zależności do trzeciego modułu importowanego przez obie strony.
Nasz mikroserwis FastAPI cierpiał z powodu okrężnych importów między database.py (zawierającym pule połączeń) a models.py (definiującym klasy ORM SQLAlchemy). Moduł bazy danych importował modele, aby wykonać początkową konfigurację schematu, podczas gdy modele importowały silnik z bazy danych do tworzenia tabel, co powodowało ImportError podczas uruchamiania aplikacji, co uniemożliwiało wdrożenie.
Oceniliśmy trzy różne rozwiązania. Przeniesienie deklaracji importu do wewnątrz funkcji create_tables() rozwiązało bezpośredni błąd, ale wprowadziło narzut wydajnościowy poprzez ponowne wykonywanie logiki importu podczas działania i zmniejszyło czytelność kodu poprzez ukrycie zależności. Stworzenie modułu interfaces.py zawierającego abstrakcyjne klasy bazowe przerwało cykl poprzez inwersję zależności, choć wymagało to znacznej refaktoryzacji i dodało złożoności pośredniej dla małej usługi. Wdrożenie kontenera wstrzykiwania zależności przy użyciu typing.Protocol Pythona pozwoliło nam zarejestrować silnik bazy danych po załadowaniu obu modułów, opóźniając faktyczne nawiązanie połączenia do czasu uruchomienia aplikacji.
Wybraliśmy podejście wstrzykiwania zależności, ponieważ utrzymywało zasady czystej architektury bez uszczerbku na wydajności. Rozwiązanie wykorzystało mechanizm Depends() FastAPI do wstrzyknięcia sesji bazy danych do obsługiwanych tras po zainicjowaniu wszystkich modułów. To wyeliminowało okrężne zależności, poprawiając testowalność poprzez wstrzykiwanie mocków, zmniejszając awarie uruchamiania o 100% i skracając czas konfiguracji testów integracyjnych o 60 procent.
Dlaczego if __name__ == "__main__" nie zapobiega błędom okrężnych importów na poziomie modułu?
Ten warunek kontroluje jedynie wykonanie kodu w kontekście głównego skryptu, a nie mechanizm importu jako takiego. Gdy Python napotyka import module, natychmiast ładowany jest i wykonywany cały plik modułu do ukończenia przed powrotem, niezależnie od jakichkolwiek obecnych sprawdzeń __name__. Błąd okrężnego importu występuje w trakcie tej fazy ładowania, szczególnie gdy interpreter próbuje rozwiązać symbole w częściowo skonstruowanej przestrzeni nazw, co oznacza, że warunek nigdy nie ma okazji do wykonania lub złagodzenia błędu.
Jak from module import name różni się od import module przy rozwiązywaniu okrężnych zależności?
Instrukcja from wykonuje natychmiastowe wyszukiwanie atrybutu w obiekcie modułu po jego pobraniu z sys.modules, ale potencjalnie przed zakończeniem wykonywania modułu. Korzystając z import module, interpreter zwraca referencję do samego obiektu modułu, co pozwala na odroczony dostęp do atrybutu do czasu zakończenia łańcucha okrężnych importów. Ta różnica wyjaśnia, dlaczego dostęp do module.name po import module udaje się, gdzie from module import name się nie udaje, ponieważ notacja kropkowa ponownie ewaluację przestrzeni nazw w czasie dostępu, a nie wiąże nazwy podczas początkowego importu.
Co się zmieniło w Pythonie 3.3+ w zakresie pakietów nazwanych i ich wpływu na rozwiązywanie okrężnych importów?
PEP 420 wprowadził domyślne pakiety nazwane, które nie mają plików __init__.py, zmieniając sposób, w jaki Python konstruuje obiekty modułów podczas importu. Tradycyjne pakiety wykonują kod __init__.py natychmiast, co zapewnia wyraźną granicę inicjalizacji, podczas gdy pakiety nazwane mogą aktywować różne sekwencje ładowania w różnych wpisach ścieżki. Kandydaci często przeoczają, że okrężne importy obejmujące pakiety nazwane mogą prowadzić do wielu obiektów modułów reprezentujących ten sam logiczny moduł (jeden na każdy wpis w ścieżce), powodując fragmentację stanu, gdzie importy w różnych plikach otrzymują różne instancje modułów pomimo identycznych deklaracji importu.