This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author kristjan.jonsson
Recipients brett.cannon, eric.snow, kristjan.jonsson, methane, pconnell, pje
Date 2013-04-05.13:07:42
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1365167262.93.0.0293704343025.issue17636@psf.upfronthosting.co.za>
In-reply-to
Content
While I'm happy that this is being ackowledged as a problem, I'm not sure changing the "import x from y" semantics is necessarily a good idea.  I mean, it is obvious to me that it means "import x, then getattr(x, "y")".  I presume that is the meaning most people associate with it.  Certainly, "y" can be any old module attribute.

To change it to actually fall back to a submodule, well. I suppose if you could explain it roughly like "y = getattr(x, 'y', x.y)"  then it would be ok.

But I can think of contrived examples where this could break things:
#a.py:
from .b import util

#b.py
from . import a
from .util import util

Because of the circular import order, b.util will not exist as an attribute on b when a does its import.  So a.util will end up being util instead of util.util as one might expect.

I'm basically saying that it is possible that the fallback to submodule will occur, where the successful getattr would occur later and return something different than the submodule.  Possible. But perhaps very much an edge case :)
History
Date User Action Args
2013-04-05 13:07:43kristjan.jonssonsetrecipients: + kristjan.jonsson, brett.cannon, pje, methane, eric.snow, pconnell
2013-04-05 13:07:42kristjan.jonssonsetmessageid: <1365167262.93.0.0293704343025.issue17636@psf.upfronthosting.co.za>
2013-04-05 13:07:42kristjan.jonssonlinkissue17636 messages
2013-04-05 13:07:42kristjan.jonssoncreate