这是python反模式吗？ '将foo.foo导入为foo'遮盖了foo包的其余部分

Question

假设我从包含模块foo.py软件包pack开始。

pack/
pack/__init__.py
pack/foo.py        # Defines class Foo

但是出于foo.py原因，我决定需要将foo.py移到子包中。 也许我的foo非常强大，我需要更多功能来对其进行管理。 由于子包全部与foo有关，因此我也将其命名为foo ，所以现在我们有了

pack/
pack/__init__.py
pack/foo
pack/foo/__init__.py
pack/foo/foo.py        # Defines class Foo

我说“ Ah”，“我可以使事情向后兼容，并避免在调用代码时用pack/__init__.py的以下import导致pack.foo.foo.Foo()的过度pack/__init__.py ……

$ cat pack/__init__.py
import foo.foo as foo

...以便我可以使用pack.foo.Foo()初始化Foo 。”

不幸的是，这意味着模块foo.py了foo包的其余部分，因此只有pack/foo/foo.py的内容可见。

我的问题是，这就是所有预期的行为，这会上升到反模式的水平吗？ 似乎在每一步决策都具有一定意义，所以这是一条容易走的路（我有几次），直到所有激发子包的附加功能都说“嘿，我们呢？”

考虑到命名和向后兼容性，是否有Python方式将模块转换为这样的子包？ foo.foo.Foo特别令人讨厌（尽管使用datetime.datetime ），但是答案可能是“只是处理它”并吃掉了向后的不兼容性。 我开玩笑地将from foo import *放在某个地方，但这似乎是错误的。 还是我缺少一些简单的解决方案？

Answer 1

尽管我说过真正的解决方案是避免深度嵌套的名称空间，但我认为解决该问题的最佳方法可能是将pack/foo/foo.py的内容移至pack/foo/__init__.py文件。 这样，您仍然可以在pack.foo包中包含其他模块，而且还可以从Foo类和foo.py其他任何位置（与pack.foo相同）访问其他模块。