Re: PEP 420: Implicit Namespace Packages

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?

> By the way, I finished reading the rest of the PEP, and with regard to
> auto-updating paths, I want to mention that it wasn't me who originally
> brought up issues about auto-update, it was someone on Python-Dev, and
> the use cases were discussed there.  Also, I would challenge the
> argument about it being a major block to implementation, since the
> implementation is straightforward (and TONS simpler than setuptools'
> approach to the problem).
>
> I guess my point is that if we're not going to do auto-updates from the
> start, it's kind of going to rule it out in the long term as well, so if
> that's the intention it should be explicitly addressed.  I don't want to
> see it just get ruled out by default due to not being done now, and then
> not being able to be done later.

Okay. I'll take a look at it tomorrow to see what's involved and if
we're backing ourselves into a corner or not.

Thanks.

Eric.