[Python-Dev] PEP 3147: PYC Repository Directories

[Guido van Rossum]

On Sat, Feb 6, 2010 at 12:21 PM, Barry Warsaw <barry at 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)