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