It certainly affects the quality, yes.
I also understand why it happens:
When importing X.Y, Y isn't actually put into X's dict until it is fully
initialized. It is, however put temporarily in sys.modules["X.Y"]
hence, "import X.Y" on a partially initialized submodule Y will work, whereas
"from X import Y" won't.
Fixing this within the "from X import Y" mechanism would add an additional
strain on the already complex import protocol (as defined in pep 302), I think.
Which is why I wonder if the relative import syntax ought to be allowed for
"import X" since that syntax does not involve a getattr.
("from X import Y" necessarily means strictly a getattr, since Y can both be
any attribute of X, not just a submodule)
As for ways around this: Note that this is a language design question, not a
software architecture one. It is possible to work around these issues,
but it is not always nice. Python is one of those languages that allow cyclic
module dependencies and it is a very nice way to separate code
by functionality, if not by dependency. It is one of the good things about
Python and we should try to make sure that we allow such
architectural freedom to continue to work.
Also, relative imports are apparently falling into favor, having only
marginally been accepted at the time of pep 328, so we should perhaps
find a way for these two things to co-exist :)
I'm not sure that
http://bugs.python.org/issue992389
warrants a fix. This issue is about general attributes of a module.
In the general case, this is probably unfixable. But access to a partially
constructed
module hierarchy through the import mechanism ought to be possible.
K
From: Nick Coghlan [mailto:ncogh...@gmail.com]
Sent: 1. apríl 2013 22:53
To: Kristján Valur Jónsson
Cc: python-dev@python.org
Subject: Re: [Python-Dev] relative import circular problem
with partially initialized modules, but not the former, rendering two sibling
modules unable to import each other using the relative syntax.
This is really a quality-of-implementation issue in the import system rather
than a core language design problem. It's just that those of us with the
knowledge and ability to fix it aren't inclined to do so because circular
imports usually (although not quite always) indicate a need to factor some
common code out into a third support module imported by both of the original
modules. At that point, the code is cleaner and more decoupled, and the uneven
circular import support ceases to be a problem for that application.
If you're interested in digging further, see http://bugs.python.org/issue992389
(this should also be a *lot* easier to fix now we're using importlib than it
ever would have been while we were
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
