Re: PEP 420: Implicit Namespace Packages

On Wed, May 2, 2012 at 9:23 PM, Barry Warsaw <[email protected]> wrote:

> On May 02, 2012, at 08:58 PM, Eric V. Smith wrote:
>
> >On 5/2/2012 5:05 PM, PJ Eby wrote:
> >
> >>     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.)
> >
> >I can go either way on this, but would lean toward __file__ not being
> >set. Brett: what's your opinion?
>
> I rather like __file__ not existing, although I haven't really thought
> about
> the practical effects.  PJE makes a good argument though.
>

There's a counterargument that I realized later: PEP 302 currently requires
that __file__ be set, AND that it be a string.  "The privilege of not
having a __file__ attribute at all is reserved for built-in modules."

(Of course, that argues equally against __file__ being None, so I'm not
sure it helps any to point that out!)

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.

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