[Python-Dev] PEP 3147 ready for pronouncement and merging
steve at holdenweb.com
Fri Apr 16 06:10:08 CEST 2010
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.
>> 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.
>> 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`.
>> >>> import foo
>> >>> foo.__file__
>> # baz is a package
>> >>> import baz
>> >>> baz.__file__
>> 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
>> 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`.
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/
More information about the Python-Dev