[Python-Dev] Broken import?

[Nick Coghlan]

Terry Reedy wrote:
> Terry Reedy wrote:
>> Guido van Rossum wrote:
> 
>>>> The reason seems to be that until the outermost import (in this case
>>>> p.b) is completed, while sys.modules has the (incomplete) modules 'p',
>>>> 'p.a' and 'p.b', the attributes p.a and p.b aren't added until after
>>>> their import is completed. Which it isn't during recursive import.
>>>> Apparently 'from <anything> import <something>' looks for the
>>>> <something> attribute in the <parent> object. This is because
>>>> "from...import" can also be used to import objects other than modules
>>>> (e.g. "from M import C"). I'm guessing that setting the attribute is
>>>> delayed until the import is totally complete, because upon a failed
>>>> import we remove the half-imported module object from sys.modules, but
>>>> apparently we didn 't want to be in the business of removing the
>>>> attribute from the parent package, so that's only set after the import
>>>> is deemed successful.
> 
> I remember a pydev discussion on this point.

The quote from Fredrik in Guido's original message sounded familiar.
Checking my nosy list on the tracker brought me to the following issue:

http://bugs.python.org/issue992389

Jim Fulton's example in that tracker issue shows that with a bit of
creativity you can provoke this behaviour *without* using a from-style
import. Torsten Bronger later brought up the same issue that Fredrik did
- it prevents some kinds of explicit relative import that look like they
should be fine.

It's starting to look to me like the "set in advance and delete on
failure" approach taken with sys.modules may make sense for the
attributes in the parent package after all. Given the way that import is
defined, I suspect that is easier said than done though...

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------