main.py
フォルダー内で呼び出されるスクリプトで作業している場合project
、1 つのオプションは、フォルダーに配置することです。project/work.pyc
これにより、モジュールはコードと同じ作業ディレクトリにあるため、インポート可能になります。
Python がインポート ステートメントを解決する方法は、次のように機能します (簡略化)。
使用している Python インタープリター (/usr/bin/python2.6
たとえば、システム上に複数存在する可能性があります) には、インポート可能なコードを探す検索パスのリストがあります。このリストは入ってsys.path
おり、インタプリタを起動して次のように出力することで見ることができます:
>>> import sys
>>> from pprint import pprint
>>> pprint(sys.path)
sys.path
通常、標準ライブラリからのモジュールへのパス、追加のインストール済みパッケージ (通常はサイト パッケージ内)、および場合によっては他のサードパーティ モジュールへのパスが含まれます。
のようなことをするとimport foo
、Python は最初にfoo.py
、スクリプトが存在するディレクトリに呼び出されたモジュールがあるかどうかを調べます。そうでない場合は、検索sys.path
してそこからインポートしようとします。
私が言ったように、この説明は少し単純化されています。詳細は、モジュールの検索パスに関するセクションで説明されています。
注 1:*.pyc
渡された
のはコンパイル済みの Python バイトコードです。つまり、その内容はバイナリであり、*.py
通常扱うソース コードとは対照的に、Python 仮想マシンによって実行される命令が含まれています。
注 2:
先生からのアドバイスfrom work import *
はかなり悪いアドバイスです。対話型インタープリターでテスト目的でこれを行うことは問題ないかもしれませんが、実際のコードでは決してそれを行うべきではありません。代わりに、次のようなことをする必要がありますfrom work import chop, hack
主な理由:
- 名前空間の汚染。必要のないものをインポートする可能性がありますが、それでもグローバル名前空間を汚染します.
- 可読性。他の誰かのコードを読んでどこ
foo
から来たのだろうと思ったら、上にスクロールしてインポートを見てください。どこからインポートされたのか正確にわかります。その人が を使用した場合import *
、それはできません。