<br><br><div class="gmail_quote">On Wed, Feb 3, 2010 at 13:33, "Martin v. Löwis" <span dir="ltr"><<a href="mailto:martin@v.loewis.de">martin@v.loewis.de</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">Guido van Rossum wrote:<br>
> On Wed, Feb 3, 2010 at 12:47 PM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
>> On the issue of __file__, I'd suggesting not being too hasty in<br>
>> deprecating that in favour of __source__. While I can see a lot of value<br>
>> in having it point to the source file more often with a different<br>
>> attribute that points to the cached file, I don't see a lot of gain to<br>
>> compensate for the pain of changing the name of __file__ itself.<br>
><br>
> Can you clarify? In Python 3, __file__ always points to the source.<br>
> Clearly that is the way of the future. For 99.99% of uses of __file__,<br>
> if it suddenly never pointed to a .pyc file any more (even if one<br>
> existed) that would be just fine. So what's this talk of switching to<br>
> __source__?<br>
<br>
</div>I originally proposed it, not knowing that Python 3 already changed the<br>
meaning of __file__ for byte code files.<br>
<br>
What I really wanted to suggest is that it should be possible to tell<br>
what gets really executed, plus what source file had been considered.<br>
<br>
So if __file__ is always the source file, a second attribute should tell<br>
whether a byte code file got read (so that you can delete that in case<br>
you doubt it's current, for example).<br>
<br></blockquote><div><br></div><div>What should be done for loaders? Right now we have get_filename() which is what __file__ is to be set to. For importlib there is source_path and bytecode_path, but both of those are specified to return None in the cases of source or bytecode are not available, respectively.</div>
<div><br></div><div>The bare minimum, I think, is we need loaders to have mehod(s) that return the path to the source -- whether it exists or not, to set __file__ to -- and the path to bytecode if it exists -- to set __compiled__ or whatever attribute we come up with. That suggests to me either two new methods or one that returns a two-item tuple. We could possibly keep get_filename() and say that people need to compare its output to what source_path()-equivalent method returns, but that seems bad if the source location needs to be based on the bytecode location.</div>
<div><br></div><div>My thinking is we deprecate get_filename() and introduce some new method that returns a two-item tuple (get_paths?). First item is where the source should be, and the second is where the bytecode is if it exists (else it's None). Putting both calculations into a single method seems better than a source_path()/bytecode_path() as the latter would quite possibly need source_path() to call bytecode_path() on its own to calculate where the source should be if it doesn't exist on top of the direct call to get_bytecode() for setting __compiled__ itself.</div>
<div><br></div><div>-Brett</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Regards,<br>
<font color="#888888">Martin<br>
</font><div><div></div><div class="h5"><br>
<br>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-dev" target="_blank">http://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="http://mail.python.org/mailman/options/python-dev/brett%40python.org" target="_blank">http://mail.python.org/mailman/options/python-dev/brett%40python.org</a><br>
</div></div></blockquote></div><br>