[Import-SIG] New PEP draft: "Simplified Package Layout and Partitioning"
pje at telecommunity.com
Tue Aug 16 23:31:09 CEST 2011
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
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.
More information about the Import-SIG