[Import-SIG] PEP 420: Implicit Namespace Packages
pje at telecommunity.com
Thu May 3 06:37:25 CEST 2012
On Wed, May 2, 2012 at 9:23 PM, Barry Warsaw <barry at python.org> 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
> >> 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Import-SIG