[Import-SIG] PEP 420: Implicit Namespace Packages

[Brett Cannon]

On Thu, May 3, 2012 at 2:23 AM, Nick Coghlan <ncoghlan at gmail.com> 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.
>

I'm going to roll my replies all into this email to keep things simple.

So, to the people not wanting to set __file__, that  (probably) won't fly
because it has been documented for years that built-in modules are the only
things that don't define __file__. Or we at least need to explain to people
how to tell the difference in a backwards-compatible fashion (e.g.
``module.__name__ in sys.builtin_module_names``).


>
> My own preference is for markers like "<frozen>", "<namespace>" and
> "<builtin>".
>

So I would have said that had experience with the stdlib not big me on
this. In my situation, the trace module was checking file, and if __file__
didn't contain "<frozen>" or "<doctest" it would try to read it as a path,
and then error out if it couldn't open the file. Now I updated it to
startswith('<') and endswith('>'), but I wonder how many people made a
similar whitelist approach. And while having __file__ to None or
non-existent will take about the same amount of time to fix, it is less
prone to silly whitelisting like what the trace module had.


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

But that's because there are no other introspection options to tell where
the module originated, unlike modules which have __loader__.


>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Import-SIG mailing list
> Import-SIG at python.org
> http://mail.python.org/mailman/listinfo/import-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/import-sig/attachments/20120503/f0661c26/attachment.html>