Re: PEP 420: Implicit Namespace Packages

On Wed, May 2, 2012 at 6:23 AM, Eric V. Smith <[email protected]> wrote:

> If it's the latter: yeah, it's a little strange. But find_module knows
> something that the caller needs to be told. It seemed easiest to add
> another possible return type. Any other suggestions?
>

It seems quite elegant to me.

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.

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

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