Re: PEP 420: Implicit Namespace Packages

On Thu, May 3, 2012 at 2:37 PM, PJ Eby <[email protected]> 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>".

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)

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.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia