Re: PEP 420: Implicit Namespace Packages

On Thu, May 3, 2012 at 12:15 PM, Barry Warsaw <[email protected]> wrote:

> On May 03, 2012, at 10:48 AM, Brett Cannon wrote:
>
> >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__.
>
> Okay, but *why* is this the rule, other than that PEP 302 says it?  IOW,
> PEP
> 302 doesn't give much of a rationale for the rule, and I suspect it just
> reflected the reality back in 2002.
>

Exactly. I am willing to be that historically it's just because that was
the only way you could tell what was or was not a built-in module.


>
> >Or we at least need to explain to people how to tell the difference in a
> >backwards-compatible fashion.
>
> Definitely, and I think that would be fine to include in PEP 420.
>
> >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.
>
> See what I mean about arbitrary and underdocumented? :)
>

I don't remind me about "arbitrary and underdocumented" when it comes to
the import system. =P

-Brett


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

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