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/ _______________________________________________ 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
