[Python-Dev] PEP 3147 ready for pronouncement and merging (original) (raw)

Steve Holden 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. 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/

More information about the Python-Dev mailing list