Nick Coghlan added the comment: Right, this problem only arises with import cycles, and that's why we resisted making eager submodule resolution work *at all* for so long (issue 992389 was filed way back in 2004).
We only conceded the point (with issue 17636 being implemented for 3.5) specifically to address a barrier to adoption for explicit relative imports, as it turned out that "from . import bar" could fail in cases where "import foo.bar" previously worked. The best explanation I could find for that rationale in the related python-dev thread is PJE's post here: https://mail.python.org/pipermail/python-dev/2013-April/125121.html What Victor's python-ideas thread pointed out is that there are actually *3* flavours of import where this particular circular reference problem can come up: # Has worked as long as Python has had packages, # as long as you only lazily resolve foo.bar in # function and method implementations import foo.bar # Has worked since 3.5 due to the IMPORT_FROM # change that falls back to a sys.modules lookup from foo import bar # Still gives AttributeError since it # eagerly resolves the attribute lookup import foo.bar as bar While I think the architectural case for allowing this kind of circular dependency between different top level namespaces is *much* weaker than that for allowing it within packages, I do think there's a reasonable consistency argument to be made in favour of ensuring that `from foo import bar` and `import foo.bar as bar` are functionally equivalent when `bar` is a submodule of `foo`, especially since the latter form makes it clearer to the reader that `bar` *is* a submodule, rather than any arbitrary attribute. I don't think it's a big problem in practice (so I wouldn't spend any time on implementing it myself), but the notion of an IMPORT_ATTR opcode for the "import x.y.z as m" case that parallels IMPORT_FROM seems architecturally clean to me in a way that the proposed resolutions to issue 992389 weren't. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30024> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
