[Import-SIG] PEP 420: Implicit Namespace Packages

[Nick Coghlan]

On Fri, May 4, 2012 at 10:05 AM, PJ Eby <pje at telecommunity.com> wrote:
> On Thu, May 3, 2012 at 6:20 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> I'd still prefer to just officially bless the existing "<whatever>"
>> convention for non-filesystem imports over encouraging type checks on
>> __loader__ or defining a new introspection interface for loaders.
>>
>> If we say "this is the stdlib convention" people are going to start using
>> the same check as is now used in traceback.py
>>
>> The precedent is there with code objects, and I think it's a good example
>> to follow.
>
> Note that this messes with the idea of using the first directory as filename
> -- anybody who joins with os.path.dirname(__file__) is going to get a mess
> (on regular filesystem paths), which is (I'm guessing) why the trailing
> separator idea was proposed in the first place.
>
> Which kind of brings us full circle on that point.  I suppose we could just
> say screw it, anybody implementing VFS importers had darn well better
> understand os.path.join and friends, since PEP 302 requires it for get_data
> anyway.

Yep. It also means VFS importers are officially free to put all the
metadata they want inside the angle brackets, secure in the knowledge
that everyone else should be treating it as an opaque blob. It then
becomes a way for them to pass necessary info to get_data() *without*
having to create distinct loader instances for every module.

Arguably, we should also be adding the angle brackets in zipimporter
(since those aren't real filesystem paths).

> Still seems like a wart, but oh well.  OTOH, maybe it's better for people
> munging __file__ to get a weird error all the time with namespace packages,
> instead of something that works some of the time, and fails later?

Right. Otherwise we'd get layout dependent behaviour where dubious
cross-portion references worked if all portions were installed to the
same path segment, but then failed if they were split across multiple
segments.

Cheers,
Nick.

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