Python循環インポート？

だから私はこのエラーを得ています

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

そして、私は同じimportステートメントをさらに使用して、それが機能することを確認できますか？循環インポートについての不文律はありますか？コールスタックのさらに下で同じクラスを使用するにはどうすればよいですか？

jpmc26の答えは間違いないと思います、循環インポートではあまりにも多くのことになります。正しく設定すれば、問題なく動作します。

これを行う最も簡単な方法はimport my_module、ではなく構文を使用することですfrom my_module import some_object。前者は、my_module含まれている場合でも、ほとんど常に機能します。後者は、my_objectがですでに定義されている場合にのみ機能しmy_moduleます。循環インポートではそうでない場合があります。

あなたのケースに特化するために：直接変更entities/post.pyするのではなく、変更してimport physicsから参照してみてください。同様に、変更するだけでなく、使用してから使用します。physics.PostBodyPostBodyphysics.pyimport entities.postentities.post.PostPost

モジュール（またはそのメンバー）を初めてインポートすると、モジュール内のコードは他のコードと同様に順次実行されます。たとえば、関数の本体と同じように扱われます。アンはimport、他の（代入、関数コール、などのコマンドだけでdef、class）。インポートがスクリプトの先頭で発生すると想定すると、次のようになります。

• あなたは、インポートしようとするWorldからworld、worldスクリプトが実行されます。
• worldスクリプトの輸入Field引き起こし、entities.fieldスクリプトが実行取得します。
• このプロセスはentities.post、インポートを試みたためにスクリプトに到達するまで続きますPost
• entities.postスクリプトが原因physicsそれが輸入しようとするために実行されるモジュールをPostBody
• 最後に、physicsインポートしようとしますPostからentities.post
• entities.postモジュールがメモリに存在するかどうかはまだわかりませんが、実際には問題ありません。モジュールがメモリ内にないか、定義するための実行が完了Postしていないため、モジュールにはまだメンバーがありませんPost
• どちらPostにしても、インポートするものがないためエラーが発生します

だから、いいえ、それは「コールスタックでさらに上へ」ではない。これは、エラーが発生した場所のスタックトレースですPost。つまり、そのクラスにインポートしようとしたときにエラーが発生しました。循環インポートは使用しないでください。せいぜい、メリットはごくわずか（通常はメリットがない）で、このような問題を引き起こします。それを維持している開発者には負担がかかり、壊れないように卵の殻の上を歩くように強いられます。モジュール構成をリファクタリングします。

循環依存関係を理解するには、Pythonが基本的にスクリプト言語であることを覚えておく必要があります。メソッド外のステートメントの実行はコンパイル時に行われます。Importステートメントはメソッド呼び出しと同じように実行されます。それらを理解するには、メソッド呼び出しのように考える必要があります。

インポートを行う場合、何が起こるかは、インポートするファイルがモジュールテーブルに既に存在するかどうかによって異なります。存在する場合、Pythonは現在シンボルテーブルにあるものを使用します。そうでない場合、Pythonはモジュールファイルの読み取りを開始し、そこで見つかったものをコンパイル、実行、インポートします。コンパイル時に参照されたシンボルは、コンパイラによって表示されたか、まだ表示されていないかによって、検出されるかどうかが決まります。

2つのソースファイルがあるとします。

ファイルX.py

def X1:
    return "x1"

from Y import Y2

def X2:
    return "x2"

ファイルY.py

def Y1:
    return "y1"

from X import X1

def Y2:
    return "y2"

ここで、ファイルX.pyをコンパイルするとします。コンパイラは、まずメソッドX1を定義してから、X.pyのインポートステートメントをヒットします。これにより、コンパイラーはX.pyのコンパイルを一時停止し、Y.pyのコンパイルを開始します。その後すぐに、コンパイラーはY.pyのインポートステートメントにヒットします。X.pyはすでにモジュールテーブルにあるため、Pythonは既存の不完全なX.pyシンボルテーブルを使用して、要求されたすべての参照を満たします。X.pyのimportステートメントの前に現れるシンボルはすべてシンボルテーブルにありますが、その後のシンボルはありません。X1はimportステートメントの前に表示されるので、正常にインポートされます。次に、PythonはY.pyのコンパイルを再開します。そうすることで、Y2を定義し、Y.pyのコンパイルを終了します。次に、X.pyのコンパイルを再開し、Y.pyシンボルテーブルでY2を見つけます。コンパイルは最終的にエラーなしで完了します。

コマンドラインからY.pyをコンパイルしようとすると、非常に異なることが起こります。Y.pyのコンパイル中に、コンパイラーはY2を定義する前にインポートステートメントにヒットします。次に、X.pyのコンパイルを開始します。すぐに、Y2を必要とするX.pyのインポートステートメントにヒットします。しかし、Y2は未定義なので、コンパイルは失敗します。

X.pyを変更してY1をインポートする場合、どのファイルをコンパイルしても、コンパイルは常に成功することに注意してください。ただし、ファイルY.pyを変更してシンボルX2をインポートすると、どちらのファイルもコンパイルされません。

モジュールX、またはXによってインポートされたモジュールが現在のモジュールをインポートする可能性がある場合は常に、以下を使用しないでください。

from X import Y

循環インポートがあると思うときはいつでも、他のモジュールの変数へのコンパイル時参照を避ける必要があります。無邪気に見えるコードを考えてみましょう：

import X
z = X.Y

このモジュールがXをインポートする前に、モジュールXがこのモジュールをインポートするとします。さらに、Yがimportステートメントの後のXで定義されているとします。そうすると、このモジュールがインポートされるときにYは定義されず、コンパイルエラーが発生します。このモジュールが最初にYをインポートする場合は、それで問題ありません。しかし、同僚の1人が無邪気に3番目のモジュールの定義の順序を変更すると、コードが壊れます。

場合によっては、他のモジュールが必要とするシンボル定義の下にインポート文を移動することにより、循環依存関係を解決できます。上記の例では、importステートメントの前の定義が失敗することはありません。コンパイル順によっては、インポート文以降の定義が失敗する場合があります。インポートされたシンボルがコンパイル時に必要とされない限り、インポートステートメントをファイルの最後に置くこともできます。

モジュール内でimportステートメントを下に移動すると、実行していることがわかりにくくなることに注意してください。モジュールの上部にある次のようなコメントでこれを補正します。

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

一般にこれは悪い習慣ですが、回避するのが難しい場合もあります。

私のように、Djangoからこの問題が発生した場合は、ドキュメントが解決策を提供していることを知っておく必要があります。https： //docs.djangoproject.com/en/1.10/ref/models/fields/#foreignkey

「...別のアプリケーションで定義されたモデルを参照するには、完全なアプリケーションラベルでモデルを明示的に指定できます。たとえば、上記のManufacturerモデルがproductionという別のアプリケーションで定義されている場合は、次を使用する必要があります。

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

この種の参照は、2つのアプリケーション間の循環インポートの依存関係を解決するときに役立ちます。...」

このモジュールのオブジェクトを必要とする関数（のみ）内にモジュールをインポートすることができました。

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

かなり複雑なアプリでこの問題に遭遇すると、すべてのインポートをリファクタリングするのが面倒になる可能性があります。PyCharmはこのためのクイックフィックスを提供し、インポートされたシンボルのすべての使用法も自動的に変更します。

私は以下を使用していました：

from module import Foo

foo_instance = Foo()

しかし、取り除くためにcircular reference私は次のことをしましたそしてそれはうまくいきました：

import module.foo

foo_instance = foo.Foo()