[Import-SIG] PEP 420: Implicit Namespace Packages

[Eric V. Smith]

On 5/3/2012 2:23 AM, Nick Coghlan wrote:
> On Thu, May 3, 2012 at 2:37 PM, PJ Eby <pje at telecommunity.com> wrote:
>> Still, code that expects to do something with a package's __file__ is
>> *going* to break somehow with a namespace package, so it's probably better
>> for it to break sooner rather than later.
> 
> My own preference is for markers like "<frozen>", "<namespace>" and "<builtin>".

It looks like "<frozen>" is indeed used, but built in modules do not set
__file__. So I don't really see that as a precedent for setting it to
something, but I do agree with most of your points below.

> They're significantly nicer to deal with when dumping module state for
> diagnostic purposes. If I get a KeyError on __file__, or an
> AttributeError on NoneType when all I'm trying to do is display data,
> it's annoying.
> 
> Standardising on a pattern also opens up the possibility of doing
> something meaningful with it in get_data() later. One of the
> guarantees of PEP 302 if that you should be able to do this:
> 
>   data_ref = os.path.join(__file__, relative_ref)
>   data =  __loader__.get_data(data_ref)
> 
> That should really only blow up in get_data(), *not* on the
> os.path.join step. Ideally, you should also be able to do this:
> 
>   data_ref = os.path.join(mod.__file__, relative_ref)
>   data =  mod.__loader__.get_data(data_ref)

While I embrace the pattern, I don't see how it could ever work for a
namespace package. The defining quality is that the namespace package
itself doesn't contain any files. And NamespaceLoader doesn't define
get_data for this reason.

> I see it as being similar to the mandatory file attribute on code
> objects - placeholders like "<stdin>" and "<string>" are a lot more
> informative when errors occur than just using None, even though
> neither of them is a valid filesystem path.

So the 4 options on the table are:
1. Add a (possibly meaningless) trailing slash character.
2. Use None.
3. Do not set it.
4. Set it to "<namespace>".

We'll discuss it today at our sprint.