[Python-Dev] PEP 3147 ready for pronouncement and merging

[Steve Holden]

Guido van Rossum wrote:
[...]
>> Implementation strategy
>> =======================
>>
>> This feature is targeted for Python 3.2, solving the problem for those
>> and all future versions.  It may be back-ported to Python 
> 
> Is there time given that 2.7b1 was released?
> 
I would hope we have learned out lesson about cramming new features in
so late in the day, and this *is* a new feature, isn't it? Surely it
therefore can't be added in a bugfix release, which in turn means it
will never be implemented in Python 2 (given that 2.7 is envisaged as
the last Py2 release).

>> Vendors are free to backport the changes to earlier distributions as
>> they see fit.
>>
Really?

>>
>> Effects on existing code
>> ========================
>>
>> Adoption of this PEP will affect existing code and idioms, both inside
>> Python and outside.  This section enumerates some of these effects.
>>
>>
>> __file__
>> ---------
>>
>> In Python 3, when you import a module, its `__file__` attribute points
>> to its source `py` file (in Python 2, it points to the `pyc` file).  A
>> package's `__file__` points to the `py` file for its `__init__.py`.
>> E.g.::
>>
>>    >>> import foo
>>    >>> foo.__file__
>>    'foo.py'
>>    # baz is a package
>>    >>> import baz
>>    >>> baz.__file__
>>    'baz/__init__.py'
>>
>> Nothing in this PEP would change the semantics of `__file__`.
>>
>> This PEP proposes the addition of an `__cached__` attribute to
>> modules, which will always point to the actual `pyc` file that was
>> read or written.  When the environment variable
>> `$PYTHONDONTWRITEBYTECODE` is set, or the `-B` option is given, or if
>> the source lives on a read-only filesystem, then the `__cached__`
>> attribute will point to the location that the `pyc` file *would* have
>> been written to if it didn't exist.  This location of course includes
>> the `__pycache__` subdirectory in its path.
> 
> Hm. I wish there was a way to find out whether the bytecode (or
> whatever) actually *was* read from this file. __file__ in Python 2
> supports this (though not in Python 3).
> 
There also seems to be some complexity in this specification. Does the
intgerpreter go through the analysis of whether the __pycache__
directory could be created in order to provide the correct value for
"the location that the .pyc file would have been written to if it didn't
exist"?

>> For alternative Python implementations which do not support `pyc`
>> files, the `__cached__` attribute may point to whatever information
>> makes sense.  E.g. on Jython, this might be the `.class` file for the
>> module: `__pycache__/foo.jython-32.class`.  Some implementations may
>> use multiple compiled files to create the module, in which case
>> `__cached__` may be a tuple.  The exact contents of `__cached__` are
>> Python implementation specific.
>>
>> It is recommended that when nothing sensible can be calculated,
>> implementations should set the `__cached__` attribute to `None`.
>>
>>
[...]

regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
See PyCon Talks from Atlanta 2010  http://pycon.blip.tv/
Holden Web LLC                 http://www.holdenweb.com/
UPCOMING EVENTS:        http://holdenweb.eventbrite.com/