[Import-SIG] New PEP draft: "Simplified Package Layout and Partitioning"

[P.J. Eby]

At 09:13 PM 8/16/2011 +0200, Greg Slodkowicz wrote:
> > I do have a rough
> > (i.e. utterly untested and probably bug-ridden) draft rewrite of
> > _gcd_import() and associated functions, if you'd like to take a look at it:
> >
> > Â  Â http://pastebin.com/6e29v8LR
>
>I haven't run the code but I don't currently see why this approach
>shouldn't work. I've been thinking about reimplementing _gcd_import()
>like this but wasn't sure it wouldn't interfere with the way importlib
>is designed.

It shouldn't.  Since importlib is supposed to be as 
backward-compatible as possible with the C implementation, and the C 
implementation was iterative, it should be even *more* correct to 
implement it with iteration.  ;-)


>I followed the approach in 'standard' import, i. e. to leave the
>parent modules be even if importing the child fails but I guess it
>doesn't make much sense to have essentially empty packages hanging
>around. But then again, if some of the parents are virtual and some
>'actual,' should we clear the former and leave the latter or just get
>rid of everything? I'm hoping there is not much legacy code that
>relies on parent modules being imported in this way ;)

If you look closely at the proposed code, I simply avoid creating the 
parents until the last possible moment.  I don't think there's any 
need to *remove* the parents if the load fails; the idea is just that 
a virtual package's module doesn't exist until a submodule is *found* 
(whether or not it's successfully *loaded*).

I think this is a reasonable compromise, as it ensures that the 
module itself will see the parents, and that if somehow something 
keeps a reference it won't end up stale/invalid.

Anyway, I wrote the PEP with essentially this exact implementation 
approach in mind, though it might not be 100% clear from the PEP itself.