考虑以下场景：
您M定义了m.py一个包含函数的模块f。
可以这样调用：
import M;
M.f()
该模块增长到一个大小，在单个文件中是不切实际的。您拆分为子M模块M.X，并将以下内容放入：M.YM.ZM/__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 留下了将来容易重组的可能性。
一种选择是命名子模块_X, _Y, 并_Z传达它们是内部的。这是推荐的方法吗？
一种选择是将子模块命名为 _X、_Y 和 _Z 以表明它们是内部的。这是推荐的方法吗？
由于您不希望人们访问 MX，因此您需要移动 X.py 模块，以便它不再作为 MX 可用。您可以按照 Kaie 的建议将其删除，但是啊。因此，是的，您的建议是推荐的方法。
移至M/X.py_M/_X.py
在M/__init__.py有线from ._X import f
正如其他人所建议的那样，人们可以访问代码不应该是一个真正的问题，并且它是一种使用具有更强封装性的语言进行编程的习惯渗透到您的 Python 设计中。
子模块有利于内部代码组织，并且引用 M 留下了将来容易重组的可能性。
是的，这是我来自 C 和 C++ 并整天与 ABI 打交道时所担心的问题。但是，如果代码很小并且经过充分测试，这通常不是问题。这是您以后可以轻松解决的问题。如果有一天你决定重新组织代码，X那么_X我相信 Jenkins 可以告诉你还有什么需要更新的。:)
有一种方法，但我认为你不会喜欢它：
# M/__init__.py
from .X import *
del X
__all__ = ["x"]
您仍然可以这样做import M.X，但在使用时会抛出错误。