Nehmen wir an, ich habe die folgende Verzeichnisstruktur:

a
    __init__.py
    b
        __init__.py
        c
            __init__.py
            c_file.py
        d
            __init__.py
            d_file.py

Im a Pakete __init__.pydas c Paket wird importiert. Aber c_file.py Importe a.b.d.

Das Programm schlägt fehl, sagen b existiert nicht wann c_file.py versucht zu importieren a.b.d. (Und es existiert wirklich nicht, weil wir gerade dabei waren, es zu importieren.)

Wie kann dieses Problem behoben werden?

Sie können den Import verschieben, zum Beispiel in a/__init__.py:

def my_function():
    from a.b.c import Blah
    return Blah()

das heißt, verschieben Sie den Import, bis er wirklich benötigt wird. Allerdings würde ich mir auch meine Paketdefinitionen/-verwendungen genau ansehen, da eine zyklische Abhängigkeit wie die erwähnte auf ein Designproblem hindeuten könnte.

Wenn a von c abhängt und c von a abhängt, sind sie dann nicht tatsächlich dieselbe Einheit?

Sie sollten wirklich prüfen, warum Sie a und c in zwei Pakete aufgeteilt haben, denn entweder haben Sie Code, den Sie in ein anderes Paket aufteilen sollten (um beide von diesem neuen Paket abhängig zu machen, aber nicht voneinander), oder Sie sollten sie zusammenführen in einem Paket.

Ich habe mich das ein paar Mal gefragt (normalerweise, wenn ich mit Models zu tun habe, die voneinander wissen müssen). Die einfache Lösung besteht darin, einfach das gesamte Modul zu importieren und dann auf das zu verweisen, was Sie benötigen.

Also anstatt zu tun

from models import Student

in einem und

from models import Classroom

im anderen tun Sie es einfach

import models

in einem von ihnen, dann anrufen models.Classroom wenn du es brauchst.

Zirkuläre Abhängigkeiten aufgrund von Typhinweisen

Mit Typhinweisen gibt es mehr Möglichkeiten zum Erstellen von zirkulären Importen. Glücklicherweise gibt es eine Lösung mit der speziellen Konstante: typing.TYPE_CHECKING.

Das folgende Beispiel definiert a Vertex Klasse und ein Edge Klasse. Eine Kante wird durch zwei Scheitelpunkte definiert, und ein Scheitelpunkt verwaltet eine Liste der angrenzenden Kanten, zu denen er gehört.

Ohne Typhinweise kein Fehler

Datei: vertex.py

class Vertex:
    def __init__(self, label):
        self.label = label
        self.adjacency_list = []

Datei: edge.py

class Edge:
    def __init__(self, v1, v2):
        self.v1 = v1
        self.v2 = v2

Typ Hinweise verursachen ImportError

ImportError: Name „Edge“ kann nicht aus teilweise initialisiertem Modul „Edge“ importiert werden (höchstwahrscheinlich aufgrund eines zirkulären Imports)

Datei: vertex.py

from typing import List
from edge import Edge


class Vertex:
    def __init__(self, label: str):
        self.label = label
        self.adjacency_list: List[Edge] = []

Datei: edge.py

from vertex import Vertex


class Edge:
    def __init__(self, v1: Vertex, v2: Vertex):
        self.v1 = v1
        self.v2 = v2

Lösung mit TYPE_CHECKING

Datei: vertex.py

from typing import List, TYPE_CHECKING

if TYPE_CHECKING:
    from edge import Edge


class Vertex:
    def __init__(self, label: str):
        self.label = label
        self.adjacency_list: List['Edge'] = []

Datei: edge.py

from typing import TYPE_CHECKING

if TYPE_CHECKING:
    from vertex import Vertex


class Edge:
    def __init__(self, v1: 'Vertex', v2: 'Vertex'):
        self.v1 = v1
        self.v2 = v2

In Anführungszeichen gesetzte vs. Nicht in Anführungszeichen gesetzte Typhinweise

In Python-Versionen vor 3.10 müssen bedingt importierte Typen in Anführungszeichen gesetzt werden, wodurch sie zu „Weiterleitungsverweisen“ werden, wodurch sie vor der Laufzeit des Interpreters verborgen werden.

In Python 3.7, 3.8 und 3.9 besteht eine Problemumgehung darin, den folgenden speziellen Import zu verwenden.

from __future__ import annotations

Dies ermöglicht die Verwendung von Typhinweisen ohne Anführungszeichen in Kombination mit bedingten Importen.

Python 3.10 (Siehe PEP 563 – Aufgeschobene Bewertung von Anmerkungen)

In Python 3.10 werden Funktions- und Variablenannotationen nicht mehr zur Definitionszeit ausgewertet. Stattdessen wird eine Zeichenfolgenform im jeweiligen beibehalten Anmerkungen Wörterbuch. Statische Typprüfer sehen keinen Unterschied im Verhalten, während Tools, die Annotationen zur Laufzeit verwenden, eine verzögerte Auswertung durchführen müssen.

Die Zeichenfolgenform wird während des Kompilierungsschritts vom AST abgerufen, was bedeutet, dass die Zeichenfolgenform möglicherweise nicht die genaue Formatierung der Quelle beibehält. Hinweis: Wenn eine Anmerkung bereits ein Zeichenfolgenliteral war, wird sie dennoch in eine Zeichenfolge eingeschlossen.

Das Problem ist, dass beim Ausführen aus einem Verzeichnis standardmäßig nur die Pakete, die Unterverzeichnisse sind, als mögliche Importe sichtbar sind, sodass Sie nicht abd importieren können. Sie können jedoch bd importieren, da b ein Unterpaket von a ist.

Wenn Sie wirklich abd in importieren möchten c/__init__.py Sie können dies erreichen, indem Sie den Systempfad auf ein Verzeichnis über a ändern und den Import in ändern a/__init__.py Import abc sein

Deine a/__init__.py sollte so aussehen:

import sys
import os
# set sytem path to be directory above so that a can be a 
# package namespace
DIRECTORY_SCRIPT = os.path.dirname(os.path.realpath(__file__)) 
sys.path.insert(0,DIRECTORY_SCRIPT+"/..")
import a.b.c

Eine zusätzliche Schwierigkeit ergibt sich, wenn Sie Module in c als Skripte ausführen wollen. Hier existieren die Pakete a und b nicht. Sie können die hacken __int__.py im Verzeichnis c, um den sys.path auf das Verzeichnis der obersten Ebene zu verweisen, und importieren Sie dann __init__ in allen Modulen innerhalb von c, um den vollständigen Pfad zum Importieren verwenden zu können, bezweifle ich, dass es sich bewährt hat, zu importieren __init__.py aber es hat für meine Anwendungsfälle funktioniert.

Ich schlage folgendes Muster vor. Wenn Sie es verwenden, können die automatische Vervollständigung und die Typhinweise ordnungsgemäß funktionieren.

zyklischer_import_a.py

import playground.cyclic_import_b

class A(object):
    def __init__(self):
        pass

    def print_a(self):
        print('a')

if __name__ == '__main__':
    a = A()
    a.print_a()

    b = playground.cyclic_import_b.B(a)
    b.print_b()

zyklischer_import_b.py

import playground.cyclic_import_a

class B(object):
    def __init__(self, a):
        self.a: playground.cyclic_import_a.A = a

    def print_b(self):
        print('b1-----------------')
        self.a.print_a()
        print('b2-----------------')

Sie können die Klassen A und B nicht mit dieser Syntax importieren

from playgroud.cyclic_import_a import A
from playground.cyclic_import_b import B

Sie können den Typ des Parameters a nicht in der Methode Klasse B __ init __ deklarieren, aber Sie können ihn auf diese Weise “umwandeln”:

def __init__(self, a):
    self.a: playground.cyclic_import_a.A = a

Eine andere Lösung besteht darin, einen Proxy für die d_file zu verwenden.

Nehmen wir zum Beispiel an, Sie möchten die blah-Klasse mit der c_file teilen. Die d_file enthält also:

class blah:
    def __init__(self):
        print("blah")

Folgendes geben Sie in c_file.py ein:

# do not import the d_file ! 
# instead, use a place holder for the proxy of d_file
# it will be set by a's __init__.py after imports are done
d_file = None 

def c_blah(): # a function that calls d_file's blah
    d_file.blah()

Und in einem drin.py:

from b.c import c_file
from b.d import d_file

class Proxy(object): # module proxy
    pass
d_file_proxy = Proxy()
# now you need to explicitly list the class(es) exposed by d_file
d_file_proxy.blah = d_file.blah 
# finally, share the proxy with c_file
c_file.d_file = d_file_proxy

# c_file is now able to call d_file.blah
c_file.c_blah()