Author ncoghlan
Recipients Victor.Varvariuc, barry, brett.cannon, eric.snow, gvanrossum, irdb, ncoghlan
Date 2017-04-10.06:25:25
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1491805526.43.0.910662409597.issue30024@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2017-04-10 06:25:26ncoghlansetrecipients: + ncoghlan, gvanrossum, barry, brett.cannon, irdb, eric.snow, Victor.Varvariuc
2017-04-10 06:25:26ncoghlansetmessageid: <1491805526.43.0.910662409597.issue30024@psf.upfronthosting.co.za>
2017-04-10 06:25:26ncoghlanlinkissue30024 messages
2017-04-10 06:25:25ncoghlancreate