[Import-SIG] New PEP draft: "Simplified Package Layout and Partitioning"
ncoghlan at gmail.com
Wed Aug 17 05:24:19 CEST 2011
On Wed, Aug 17, 2011 at 7:31 AM, P.J. Eby <pje at telecommunity.com> wrote:
> 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.
I've been pondering this aspect a bit, and I'm still not sure delaying
the parent module creation until after the named module has been
definitively located makes sense.
The current algorithm is basically to break the module path up into
components, and then find and load each segment in turn. Errors in
finding or loading the later segments leave the earlier, already
loaded, segments alone.
With PEP 402, for the backwards compatibility reasons described in the
PEP, we need to distinguish the 'parent imports' from direct imports,
so we can ignore pure virtual packages in the latter case. However,
the further special casing to say 'only load the pure virtual packages
if the child module is found' seems like a needless complication. We
may end up with childless virtual packages in sys.modules *anyway* due
to failures in the load stage, so what's the advantage of avoiding
creating them just because the subsequent failure happened to occur in
the find stage?
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Import-SIG