* Added reference to py_compile and compileall
* Added reference to bdist_wininst and the Windows installer * Added reference to BDFL pronouncement on __pycache__ over .pyc
This commit is contained in:
parent
3322443f27
commit
bac0ec132f
57
pep-3147.txt
57
pep-3147.txt
|
@ -374,6 +374,25 @@ Alternative implementations for which this scheme does not make sense
|
|||
should set the `__cached__` attribute to `None`.
|
||||
|
||||
|
||||
py_compile and compileall
|
||||
-------------------------
|
||||
|
||||
Python comes with two modules, `py_compile` [15]_ and `compileall` [16]_
|
||||
which support compiling Python modules external to the built-in import
|
||||
machinery. `py_compile` in particular has intimate knowledge of byte
|
||||
compilation, so these will have to be updated to understand the new
|
||||
layout. It's possible that `compileall` could be modified to support
|
||||
legacy byte-code only file system layout.
|
||||
|
||||
|
||||
bdist_wininst and the Windows installer
|
||||
---------------------------------------
|
||||
|
||||
These tools also compile modules explicitly on installation. If they
|
||||
do not use `py_compile` and `compileall`, then they would also have to
|
||||
be modified to understand the new layout.
|
||||
|
||||
|
||||
File extension checks
|
||||
---------------------
|
||||
|
||||
|
@ -382,7 +401,7 @@ simply chops off the last character to find the matching `.py` file.
|
|||
This code will obviously fail once this PEP is implemented.
|
||||
|
||||
To support this use case, we'll add two new methods to the `imp`
|
||||
package [15]_:
|
||||
package [17]_:
|
||||
|
||||
* `imp.source_from_cache(py_path)` -> `pyc_path`
|
||||
* `imp.cache_from_source(pyc_path)` -> `py_path`
|
||||
|
@ -394,7 +413,7 @@ return reasonable values based on their own support for this PEP.
|
|||
PEP 302 loaders
|
||||
---------------
|
||||
|
||||
PEP 302 [16]_ defined loaders have a `.get_filename()` method which
|
||||
PEP 302 [18]_ defined loaders have a `.get_filename()` method which
|
||||
points to the `__file__` for a module. As part of this PEP, we will
|
||||
extend this API, to include a new method `.get_paths()` which will
|
||||
return a 2-tuple containing the path to the source file and the path
|
||||
|
@ -419,7 +438,7 @@ Alternatives
|
|||
PEP 304
|
||||
-------
|
||||
|
||||
There is some overlap between the goals of this PEP and PEP 304 [17]_,
|
||||
There is some overlap between the goals of this PEP and PEP 304 [19]_,
|
||||
which has been withdrawn. However PEP 304 would allow a user to
|
||||
create a shadow file system hierarchy in which to store `pyc` files.
|
||||
This concept of a shadow hierarchy for `pyc` files could be used to
|
||||
|
@ -474,17 +493,31 @@ approach makes it more difficult (and an ongoing task) to update any
|
|||
tools that are dependent on the file extension.
|
||||
|
||||
|
||||
.pyc
|
||||
----
|
||||
|
||||
A proposal was floated to call the `__pycache__` directory `.pyc` or
|
||||
some other dot-file name. This would have the effect on *nix systems
|
||||
of hiding the directory. There are many reasons why this was
|
||||
rejected by the BDFL [20]_ including the fact that dot-files are only
|
||||
special on some platforms, and we actually do *not* want to hide these
|
||||
completely from users.
|
||||
|
||||
|
||||
Reference implementation
|
||||
========================
|
||||
|
||||
A pure-Python reference implementation will be written using
|
||||
importlib [18]_, which may need some modifications to its API and
|
||||
importlib [21]_, which may need some modifications to its API and
|
||||
abstract base classes. Once the semantics are agreed upon and the
|
||||
implementation details are settled, we'll port this to the C
|
||||
implementation in `import.c`. We will have extensive tests that
|
||||
guarantee that the pure-Python implementation and the built-in
|
||||
implementation remain in sync.
|
||||
|
||||
Work on this code will be tracked in a Bazaar branch on Launchpad
|
||||
[22]_ until it's ready for merge into Python 3.2.
|
||||
|
||||
|
||||
Open issues
|
||||
===========
|
||||
|
@ -573,13 +606,21 @@ References
|
|||
|
||||
.. [14] Pynie: http://code.google.com/p/pynie/
|
||||
|
||||
.. [15] imp: http://www.python.org/doc/current/library/imp.html
|
||||
.. [15] py_compile: http://docs.python.org/library/py_compile.html
|
||||
|
||||
.. [16] PEP 302
|
||||
.. [16] compileall: http://docs.python.org/library/compileall.html
|
||||
|
||||
.. [17] PEP 304
|
||||
.. [17] imp: http://www.python.org/doc/current/library/imp.html
|
||||
|
||||
.. [18] importlib: http://docs.python.org/3.1/library/importlib.html
|
||||
.. [18] PEP 302
|
||||
|
||||
.. [19] PEP 304
|
||||
|
||||
.. [20] http://www.mail-archive.com/python-dev@python.org/msg45203.html
|
||||
|
||||
.. [21] importlib: http://docs.python.org/3.1/library/importlib.html
|
||||
|
||||
.. [22] https://code.launchpad.net/~barry/python/pep3147
|
||||
|
||||
|
||||
ACKNOWLEDGMENTS
|
||||
|
|
Loading…
Reference in New Issue