On Wed, Feb 3, 2010 at 13:30, "Martin v. Löwis" <mar...@v.loewis.de> wrote: >> On Wed, Feb 3, 2010 at 05:07, Antoine Pitrou <solip...@pitrou.net> wrote: >>> Barry Warsaw <barry <at> python.org> writes: >>>> Python 3 uses the .py file for __file__ but I'd like to see a transition to >>>> __source__ for that, with __cache__ for the location of the PVM, JVM, LLVM >>>> or >>>> whatever compilation cache artifact file. >>> Well, I don't think we need another transition... Just keep __file__ for the >>> source file, and add a __cache__ or __compiled__ attribute for the compiled >>> file(s). >> >> So what happens when only bytecode is present? As of right now >> __file__ is set to the path of the bytecode if no source exists >> (needed for reloading along with backwards-compatibility). Would you >> set __file__ = __compiled__? > > This is what I would propose. There are also shared libraries, so > __file__ should really point to the file that is being executed. In the > case of a source file, claiming that this is the one that gets executed > is fairly accurate even if we had actually loaded the byte code from the > cache.
I like that explanation that __file__ contains what is semantically being run and using __compiled__ to simply represent what was actually loaded. > The only case when this may be wrong is when somebody sets the > timestamp of the source file backwards, or the timestamp of the byte > code file forwards. For this case, a second attribute could help (and I > would set *that* to None if we only wrote the pyc file, but didn't read > it - a library functions would be able to tell where the pyc file should > have been written to). Well, if you are mucking with file timestamps while loading code you are just asking for trouble, so I don't think we need to worry about it. -Brett > >> Maybe, but only one of them will be used. Having to check for all of >> the possible compiled versions of a module is just a waste of time; >> you should only care about what import used to load the module. > > I agree. > > 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/archive%40mail-archive.com
