On Wed, Feb 3, 2010 at 13:33, "Martin v. Löwis" <mar...@v.loewis.de> wrote:
> Guido van Rossum wrote: > > On Wed, Feb 3, 2010 at 12:47 PM, Nick Coghlan <ncogh...@gmail.com> > wrote: > >> On the issue of __file__, I'd suggesting not being too hasty in > >> deprecating that in favour of __source__. While I can see a lot of value > >> in having it point to the source file more often with a different > >> attribute that points to the cached file, I don't see a lot of gain to > >> compensate for the pain of changing the name of __file__ itself. > > > > Can you clarify? In Python 3, __file__ always points to the source. > > Clearly that is the way of the future. For 99.99% of uses of __file__, > > if it suddenly never pointed to a .pyc file any more (even if one > > existed) that would be just fine. So what's this talk of switching to > > __source__? > > I originally proposed it, not knowing that Python 3 already changed the > meaning of __file__ for byte code files. > > What I really wanted to suggest is that it should be possible to tell > what gets really executed, plus what source file had been considered. > > So if __file__ is always the source file, a second attribute should tell > whether a byte code file got read (so that you can delete that in case > you doubt it's current, for example). > > 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. 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. 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. -Brett > Regards, > Martin > > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
