私があなたが望んでいると思うのは、これができることです:
# some_other_script.py
import module
# Do things using routines defined in module.core
Pythonに要求するimport module
と、(非常に基本的な意味で)module/__init__.py
実行され、module
オブジェクトが作成されて名前空間にインポートされます。このオブジェクト(これも非常に基本的に)には、__init__.py
実行時に発生した名前の定義などが含まれます。これらには、からアクセスできますmodule.something
。
ここで、セットアップが次のようになっている場合:
# module/__init__.py
from module.core import Clazz
c = Clazz()
print c # Note: demo only! Module-level side-effects are usually a bad idea!
をインポートするmodule
と、次のようなprintステートメントが表示されます。
<module.core.Clazz object at 0x00BBAA90>
素晴らしい。しかし、次にアクセスしようとするとc
、次のようになりますNameError
。
# some_other_script.py
import module # prints "<module.core.Clazz object at 0x00BBAA90>"
print c # NameError (c is not defined)
これは、インポートしていないためですc
。インポートしましたmodule
。代わりに、エントリポイントスクリプトが次のようになっている場合:
# some_other_script.py
import module # prints "<module.core.Clazz object at 0x00BBAA90>"
print module.c # Access c *within module*
すべてが正常に実行されます。これは、および/またはで正常に機能しますが、ワイルドインポートをいじり始めたときにスクリプトで何が起こっているのかが明確でないという理由だけで、私(およびPEP8)はこれに反対することをお勧めします。明確にするために:from core import *
from module import *
# module/core.py
def core_func():
return 1
# module/__init__.py
from core import *
def mod_func():
return 2
上記は実際にはかなり問題ありませんが、パッケージの外部から触れる理由がなくなったことを示すためにcore
「プライベート」(名前を)に変更することもできます。_core
# some_other_script.py
from module import *
print core_func() # Prints 1
print mod_func() # Prints 2