Re: PEP 420: Implicit Namespace Packages

On 05/02/2012 01:06 PM, PJ Eby wrote:

> I do see one point of concern with the spec, though.  At one point it
> says that finders must return a path without a trailing separator, but
> at another it says the package __file__ will contain a separator.
> 
> This strikes me as inconsistent, and also incompatible with
> non-filesystem-based finder implementations.  The import machinery *must
> not* assume that import path strings are filenames, so it is wrong for
> the import machinery to add a path separator that the finder did not
> include.
> 
> IOW, I don't think the spec can assume or guarantee anything about the
> strings returned by finders: it MUST treat them as opaque strings.  If
> this means that there can't be any meaningful __file__ for a namespace
> package, I think we will have to live with that.

I've come to the same conclusion myself. I actually had a draft of the
PEP that removed the word "directory", at which point it becomes obvious
that you're adding a path separator to something that might not be a
path name.

> The only alternative I see is to delegate the string manipulation back
> to the finders, or to change the return value from a string to a (file,
> path) tuple, wherein 'file' is the value to be used as __file__, and
> 'path' is the value to be used in __path__.

I don't see the value of __file__ at all in the case of namespace
packages. If it's just a hint that it's a namespace package, I think it
would be better to set __file__ to None. That would noisily break some
code that isn't likely to work anyway.

Eric.