Re: PEP 420: Implicit Namespace Packages

On Thu, May 3, 2012 at 10:48 AM, Brett Cannon <[email protected]> wrote:

>
>
> On Thu, May 3, 2012 at 2:23 AM, Nick Coghlan <[email protected]> wrote:
>
>> On Thu, May 3, 2012 at 2:37 PM, PJ Eby <[email protected]> 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.
>

That should say "So I would have agreed with that had my experience with
the stdlib in bootstrapping importlib not caused me to disagree."

Don't try to multi-task at work while in the middle of writing an email is
the lesson there. =)

-Brett

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   |   [email protected]   |   Brisbane, Australia
>> _______________________________________________
>> 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