6

次のシナリオを検討してください。

  • function を含むモジュールがM定義されています。m.pyf

    次のように呼び出すことができます。

    import M;
M.f()

  • モジュールのサイズが大きくなり、1 つのファイルに収めることが現実的ではなくなります。MサブモジュールM.X、M.Yに分割しM.Z、 に以下を入れますM/__init__.py。

    from .X import *
from .Y import *
from .Z import *

__all__ = ["f"]

    元のコードは引き続き機能します。

    import M;
M.f()

ただし、コードの新しいコンシューマーは、誤ってサブモジュールに直接アクセスする可能性があります。

import M.X;
M.X.f()

これを防ぎたいのですが、すべてのコードがサブモジュールではなく、一貫して M を直接アドレス指定しているようにします。

サブモジュールは内部コード編成のためのものであり、M を参照すると、将来的に簡単に再編成できる可能性が残ります。

1 つのオプションは、サブモジュール_Xに 、_Y、および_Zそれらが内部であることを伝える名前を付けることです。それは推奨されるアプローチですか？

4

2 に答える 2

1

1つのオプションは、サブモジュールに_X、_Y、および_Zという名前を付けて、それらが内部であることを通知することです。それが推奨されるアプローチですか？

他の人にMXにアクセスさせたくないので、X.pyモジュールを移動して、MXとして使用できなくなるようにする必要があります。Kaieが提案するように削除することもできますが、大変です。したがって、はい、あなたの提案が推奨されるアプローチです。

  1. M/X.pyに移動M/_X.py

  2. ラインM/__init__.pyを持っているfrom ._X import f

他の人が示唆しているように、人々がコードにアクセスできることは実際には問題ではないはずであり、Pythonデザインに浸透するより強力なカプセル化を備えた言語でプログラミングする習慣があります。

サブモジュールは内部コード編成の利益のためであり、Mを参照すると、将来、簡単に再編成できる可能性があります。

はい、これは私がCおよびC ++から来て、一日中ABIを扱っているときに私が抱いていた懸念事項です。ただし、コードが小さく、十分にテストされていれば、問題にならないことがよくあります。そして、これは後で簡単に修正できるようなものです。ある日、コードを再編成してそのままにすることにした場合、XJenkins_Xは他に何を更新する必要があるかを教えてくれると確信しています。:)

于 2013-03-20T22:02:16.737 に答える
0

方法はありますが、気に入らないと思います。

# M/__init__.py

from .X import *
del X
__all__ = ["x"]

引き続き実行できますがimport M.X、使用するとエラーがスローされます。

于 2013-03-20T15:44:37.697 に答える