<br><br><div class="gmail_quote">On Thu, May 3, 2012 at 2:23 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Thu, May 3, 2012 at 2:37 PM, PJ Eby <<a href="mailto:pje@telecommunity.com">pje@telecommunity.com</a>> wrote:<br>
> Still, code that expects to do something with a package's __file__ is<br>
> *going* to break somehow with a namespace package, so it's probably better<br>
> for it to break sooner rather than later.<br></div></blockquote><div><br></div><div>I'm going to roll my replies all into this email to keep things simple.</div><div><br></div><div>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``).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
</div>My own preference is for markers like "<frozen>", "<namespace>" and "<builtin>".<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
They're significantly nicer to deal with when dumping module state for<br>
diagnostic purposes. If I get a KeyError on __file__, or an<br>
AttributeError on NoneType when all I'm trying to do is display data,<br>
it's annoying.<br>
<br>
Standardising on a pattern also opens up the possibility of doing<br>
something meaningful with it in get_data() later. One of the<br>
guarantees of PEP 302 if that you should be able to do this:<br>
<br>
data_ref = os.path.join(__file__, relative_ref)<br>
data = __loader__.get_data(data_ref)<br>
<br>
That should really only blow up in get_data(), *not* on the<br>
os.path.join step. Ideally, you should also be able to do this:<br>
<br>
data_ref = os.path.join(mod.__file__, relative_ref)<br>
data = mod.__loader__.get_data(data_ref)<br>
<br>
I see it as being similar to the mandatory file attribute on code<br>
objects - placeholders like "<stdin>" and "<string>" are a lot more<br>
informative when errors occur than just using None, even though<br>
neither of them is a valid filesystem path.<br></blockquote><div><br></div><div>But that's because there are no other introspection options to tell where the module originated, unlike modules which have __loader__.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im HOEnZb"><br>
Cheers,<br>
Nick.<br>
<br>
--<br>
Nick Coghlan | <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a> | Brisbane, Australia<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Import-SIG mailing list<br>
<a href="mailto:Import-SIG@python.org">Import-SIG@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/import-sig" target="_blank">http://mail.python.org/mailman/listinfo/import-sig</a><br>
</div></div></blockquote></div><br>