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

[Greg Slodkowicz]

> 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. I would be happy to work on this further, if that's the
agreed way to go.

>> One way to get around this would be to create an empty module on each
>> import level (Foo and Foo.Bar in this case) and set appropriate
>> __path__ on each of them. To my mind, this would require changing the
>> way get_subpath() works.
>
> If I understand your proposal correctly, this introduces the problem of
> having to get rid of these dummy modules if the import fails -- and with no
> guarantee that you won't wind up with dangling references somewhere.

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 ;)

Cheers,
Greg