这是一个python反模式吗？ 'import foo.foo as foo'影响foo包的其余部分

Question

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

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

但由于原因，我决定将foo.py移到子包中。也许我的foo非常强大，我需要更多的功能来管理它。由于子包是关于foo的，我也将其命名为foo，所以现在我们已经

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

“啊”，我说，“我可以使事情向后兼容，并避免在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的内容可见。

这是所有预期的行为，我的问题是，这会上升到反模式的水平吗？看起来每个步骤的决定都有一定的意义，所以这是一条很容易徘徊的道路（我有几次），直到推动子包装的所有其他功能都说“嘿，我们呢？”

是否有一种pythonic方法可以将模块转换为这样的子包，同时考虑到命名和向后兼容性？特别是foo.foo.Foo令人厌烦（尽管datetime.datetime），但也许答案是“只处理它”并吃掉向后不兼容的东西。我玩弄了from foo import *某处，但这似乎不对。或者我错过了一些简单的解决方案？

Answer 1

尽管我的评论是真正的解决方案是为了避免这种深层嵌套的命名空间，但我认为解决问题的最佳方法是移动{{1}的内容进入pack/foo/foo.py文件。这样，您仍然可以在pack/foo/__init__.py包中包含其他模块，还可以访问pack.foo类以及Foo中与之前相同位置的任何其他模块（foo.py）