Re: PEP 420: Implicit Namespace Packages

On Wed, May 2, 2012 at 1:24 PM, Eric V. Smith <[email protected]> wrote:

> 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.


Problem is that None for __file__ would be a unique use here. Frozen
modules, for instance, typically say "<frozen>" for __file__. Now part of
the reason (I suspect) this is done is that this was the only way to tell
how the module was created, but with __loader__ now on all modules this is
redundant. So perhaps this fake value for __file__ is just outdated and not
worth perpetuating?

I vote for using __file__ as None as suggested and having people infer how
the module was created from __loader__.

_______________________________________________
Import-SIG mailing list
[email protected]
http://mail.python.org/mailman/listinfo/import-sig