Python-Zirkelimport?

Ich bekomme also diesen Fehler

Traceback (most recent call last):
  File "/Users/alex/dev/runswift/utils/sim2014/simulator.py", line 3, in <module>
    from world import World
  File "/Users/alex/dev/runswift/utils/sim2014/world.py", line 2, in <module>
    from entities.field import Field
  File "/Users/alex/dev/runswift/utils/sim2014/entities/field.py", line 2, in <module>
    from entities.goal import Goal
  File "/Users/alex/dev/runswift/utils/sim2014/entities/goal.py", line 2, in <module>
    from entities.post import Post
  File "/Users/alex/dev/runswift/utils/sim2014/entities/post.py", line 4, in <module>
    from physics import PostBody
  File "/Users/alex/dev/runswift/utils/sim2014/physics.py", line 21, in <module>
    from entities.post import Post
ImportError: cannot import name Post

und Sie können sehen, dass ich die gleiche Importanweisung weiter oben verwende und es funktioniert? Gibt es eine ungeschriebene Regel für den zirkulären Import? Wie verwende ich dieselbe Klasse weiter unten im Aufrufstapel?

Ich denke, die Antwort von jpmc26 ist zwar keineswegs falsch , aber bei zirkulären Importen zu stark. Sie können einwandfrei funktionieren, wenn Sie sie richtig eingerichtet haben.

Der einfachste Weg, dies zu tun, ist die Verwendung der import my_moduleSyntax anstelle von from my_module import some_object. Ersteres wird fast immer funktionieren, auch wenn my_modulees uns zurück importiert. Letzteres funktioniert nur, wenn my_objectes bereits in definiert ist my_module, was bei einem Zirkelimport möglicherweise nicht der Fall ist.

Um spezifisch für Ihren Fall zu sein: Versuchen Sie, entities/post.pyzu do zu wechseln , import physicsund beziehen Sie sich dann physics.PostBodynicht nur PostBodydirekt auf. In ähnlicher Weise ändern Sie physics.pyzu tun import entities.postund verwenden Sie dann entities.post.Postanstatt nur Post.

Wenn Sie ein Modul (oder ein Mitglied davon) zum ersten Mal importieren, wird der Code im Modul wie jeder andere Code nacheinander ausgeführt. zB wird es nicht anders behandelt als der Körper einer Funktion. Ein importnur ein Befehl wie jede andere (Zuordnung, ein Funktionsaufruf, def, class). Angenommen, Ihre Importe finden oben im Skript statt, dann passiert Folgendes:

• Wenn Sie versuchen, Worldaus zu importieren world, wird das worldSkript ausgeführt.
• Das worldSkript wird importiert Field, wodurch das entities.fieldSkript ausgeführt wird.
• Dieser Vorgang wird fortgesetzt, bis Sie das entities.postSkript erreichen, weil Sie versucht haben, es zu importierenPost
• Das entities.postSkript bewirkt, dass das physicsModul ausgeführt wird, weil es versucht zu importierenPostBody
• Schließlich physicsversucht, Postaus zu importierenentities.post
• Ich bin mir nicht sicher, ob das entities.postModul noch im Speicher vorhanden ist, aber es spielt wirklich keine Rolle. Entweder befindet sich das Modul nicht im Speicher, oder das Modul hat noch kein PostMitglied, da die Ausführung der Definition noch nicht abgeschlossen istPost
• In beiden Fällen tritt ein Fehler auf, da er Postnicht importiert werden kann

Also nein, es ist nicht "weiter oben im Aufrufstapel". Dies ist eine Stapelverfolgung, in der der Fehler aufgetreten ist. Dies bedeutet, dass beim Import Postin diese Klasse ein Fehler aufgetreten ist . Sie sollten keine zirkulären Importe verwenden. Bestenfalls hat es einen vernachlässigbaren Nutzen (normalerweise keinen Nutzen) und verursacht solche Probleme. Es belastet jeden Entwickler, der es wartet, und zwingt ihn, auf Eierschalen zu laufen, um ein Zerbrechen zu vermeiden. Überarbeiten Sie Ihre Modulorganisation.

Um zirkuläre Abhängigkeiten zu verstehen, müssen Sie sich daran erinnern, dass Python im Wesentlichen eine Skriptsprache ist. Die Ausführung von Anweisungen außerhalb von Methoden erfolgt zur Kompilierungszeit. Importanweisungen werden wie Methodenaufrufe ausgeführt. Um sie zu verstehen, sollten Sie sie wie Methodenaufrufe betrachten.

Wenn Sie einen Import durchführen, hängt das davon ab, ob die zu importierende Datei bereits in der Modultabelle vorhanden ist. In diesem Fall verwendet Python alles, was derzeit in der Symboltabelle enthalten ist. Wenn nicht, beginnt Python mit dem Lesen der Moduldatei und kompiliert / führt / importiert alles, was dort gefunden wird. Symbole, auf die beim Kompilieren verwiesen wird, werden gefunden oder nicht, je nachdem, ob sie vom Compiler gesehen wurden oder noch nicht gesehen wurden.

Stellen Sie sich vor, Sie haben zwei Quelldateien:

Datei X.py.

def X1:
    return "x1"

from Y import Y2

def X2:
    return "x2"

Datei Y.py.

def Y1:
    return "y1"

from X import X1

def Y2:
    return "y2"

Angenommen, Sie kompilieren die Datei X.py. Der Compiler definiert zunächst die Methode X1 und trifft dann die Importanweisung in X.py. Dies führt dazu, dass der Compiler die Kompilierung von X.py unterbricht und mit dem Kompilieren von Y.py beginnt. Kurz danach trifft der Compiler die Importanweisung in Y.py. Da X.py bereits in der Modultabelle enthalten ist, verwendet Python die vorhandene unvollständige X.py-Symboltabelle, um alle angeforderten Referenzen zu erfüllen. Alle Symbole, die vor der import-Anweisung in X.py erscheinen, befinden sich jetzt in der Symboltabelle, alle Symbole danach jedoch nicht. Da X1 jetzt vor der Importanweisung angezeigt wird, wurde es erfolgreich importiert. Python setzt dann das Kompilieren von Y.py fort. Dabei wird Y2 definiert und das Kompilieren von Y.py abgeschlossen. Anschließend wird die Kompilierung von X.py fortgesetzt und Y2 in der Y.py-Symboltabelle gefunden. Die Kompilierung wird schließlich ohne Fehler abgeschlossen.

Etwas ganz anderes passiert, wenn Sie versuchen, Y.py über die Befehlszeile zu kompilieren. Beim Kompilieren von Y.py trifft der Compiler die Importanweisung, bevor er Y2 definiert. Dann beginnt es mit dem Kompilieren von X.py. Bald trifft es die Import-Anweisung in X.py, die Y2 erfordert. Y2 ist jedoch undefiniert, sodass die Kompilierung fehlschlägt.

Beachten Sie, dass die Kompilierung immer erfolgreich ist, wenn Sie X.py so ändern, dass Y1 importiert wird, unabhängig davon, welche Datei Sie kompilieren. Wenn Sie jedoch die Datei Y.py so ändern, dass das Symbol X2 importiert wird, wird keine der Dateien kompiliert.

Verwenden Sie NICHT, wenn Modul X oder ein von X importiertes Modul das aktuelle Modul importiert:

from X import Y

Jedes Mal, wenn Sie glauben, dass es zu einem zirkulären Import kommen könnte, sollten Sie auch vermeiden, Verweise auf Variablen in anderen Modulen zu kompilieren. Betrachten Sie den unschuldig aussehenden Code:

import X
z = X.Y

Angenommen, Modul X importiert dieses Modul, bevor dieses Modul X importiert. Angenommen, Y wird nach der Importanweisung in X definiert. Dann wird Y nicht definiert, wenn dieses Modul importiert wird, und Sie erhalten einen Kompilierungsfehler. Wenn dieses Modul zuerst Y importiert, können Sie damit durchkommen. Wenn jedoch einer Ihrer Mitarbeiter die Reihenfolge der Definitionen in einem dritten Modul unschuldig ändert, wird der Code unterbrochen.

In einigen Fällen können Sie zirkuläre Abhängigkeiten auflösen, indem Sie eine Importanweisung unter die Symboldefinitionen verschieben, die von anderen Modulen benötigt werden. In den obigen Beispielen schlagen Definitionen vor der Importanweisung niemals fehl. Definitionen nach der import-Anweisung schlagen je nach Kompilierungsreihenfolge manchmal fehl. Sie können sogar Importanweisungen am Ende einer Datei einfügen, sofern beim Kompilieren keines der importierten Symbole benötigt wird.

Beachten Sie, dass das Verschieben von Importanweisungen in einem Modul Ihre Arbeit verdeckt. Kompensieren Sie dies mit einem Kommentar oben in Ihrem Modul wie folgt:

#import X   (actual import moved down to avoid circular dependency)

Im Allgemeinen ist dies eine schlechte Praxis, aber manchmal ist es schwer zu vermeiden.

Für diejenigen unter Ihnen, die wie ich aus Django zu diesem Problem kommen, sollten Sie wissen, dass die Dokumente eine Lösung bieten: https://docs.djangoproject.com/de/1.10/ref/models/fields/#foreignkey

"... Um auf Modelle zu verweisen, die in einer anderen Anwendung definiert sind, können Sie explizit ein Modell mit der vollständigen Anwendungsbezeichnung angeben. Wenn beispielsweise das obige Herstellermodell in einer anderen Anwendung namens Produktion definiert ist, müssen Sie Folgendes verwenden:

class Car(models.Model):
    manufacturer = models.ForeignKey(
        'production.Manufacturer',
        on_delete=models.CASCADE,
)

Diese Art von Referenz kann nützlich sein, wenn zirkuläre Importabhängigkeiten zwischen zwei Anwendungen aufgelöst werden. ... "

Wenn Sie in einer recht komplexen App auf dieses Problem stoßen, kann es umständlich sein, alle Ihre Importe zu überarbeiten. PyCharm bietet hierfür einen Quickfix an, der automatisch auch die Verwendung der importierten Symbole ändert.

Ich konnte das Modul innerhalb der Funktion (nur) importieren, für die die Objekte aus diesem Modul erforderlich sind:

def my_func():
    import Foo
    foo_instance = Foo()

Ich habe folgendes verwendet:

from module import Foo

foo_instance = Foo()

aber um loszuwerden, habe circular referenceich folgendes getan und es hat funktioniert:

import module.foo

foo_instance = foo.Foo()