[Import-SIG] PEP 420: Implicit Namespace Packages

[PJ Eby]

On Wed, May 2, 2012 at 1:24 PM, Eric V. Smith <eric at trueblade.com> 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.
>

Either None or a missing attribute is fine with me.  (One advantage to the
missing attribute is that it fails at the exact point where the inspecting
code needs fixing, whereas the None will get passed on to some other code
before the error manifests itsefl.)

By the way, I finished reading the rest of the PEP, and with regard to
auto-updating paths, I want to mention that it wasn't me who originally
brought up issues about auto-update, it was someone on Python-Dev, and the
use cases were discussed there.  Also, I would challenge the argument about
it being a major block to implementation, since the implementation is
straightforward (and TONS simpler than setuptools' approach to the problem).

More to the point, though, supporting auto-updates *later* is not really an
option, since we'd be changing the rules on people, and invalidating
whatever workarounds people come up with for manually updating the path.
 If namespace package __path__ objects start out as some other type than
lists, then there's no change to trip anyone up later.

I guess my point is that if we're not going to do auto-updates from the
start, it's kind of going to rule it out in the long term as well, so if
that's the intention it should be explicitly addressed.  I don't want to
see it just get ruled out by default due to not being done now, and then
not being able to be done later.

That's why my earlier question was about whether it had been discussed or
not -- there was previous discussion on it in the 402 context, and it was
left as an open issue pending BDFL comment on the basic idea of 402.  Since
then, the basic idea of treating init-less directories as namespace
packages has been blessed, so now it's time to get the auto-updates
yea-or-nay question ruled on as well.

The implementation is pretty trivial; see PEP 402 version of it here:

  http://mail.python.org/pipermail/import-sig/2012-April/000473.html

...and the PEP 420 version is even simpler, since instead of looking for a
'get_subpath()' method on the finders, it should just call find_module()
and check for a string return.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/import-sig/attachments/20120502/10cef13c/attachment.html>