On Sat, Feb 6, 2010 at 12:21 PM, Barry Warsaw <ba...@python.org> wrote: > On Feb 03, 2010, at 01:17 PM, Guido van Rossum wrote: >>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__? > > Upon further reflection, I agree. __file__ also points to the source in > Python 2.7.
Not in the 2.7 svn repo I have access to. It still points to the .pyc file if it was used. And I propose not to disturb this in 2.7, at least not by default. I'm fine though with a flag or distro-overridable config setting to change this behavior. > Do we need an attribute to point to the compiled bytecode file? I think we do. Quite unrelated to this discussion I have a use case for knowing easily whether a module was actually loaded from bytecode or not -- but I also have a need for __file__ to point to the source. So having both __file__ and __compiled__ makes sense to me. When there is no source code but only bytecode I am file with both pointing to the bytecode; in that case I presume that the bytecode is not in a __pyr__ subdirectory. For dynamically loaded extension modules I think both should be left unset, and some other __xxx__ variable could point to the .so or .dll file. FWIW the most common use case for __file__ is probably to find data files relative to it. Since the data won't be in the __pyr__ directory we couldn't make __file__ point to the __pyr__/....pyc file without much code breakage. (Yes, I am still in favor of the folder-per-folder model.) -- --Guido van Rossum (python.org/~guido) _______________________________________________ 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
