Add a section discussion the options for bytecode-only packagers.
This commit is contained in:
parent
d3b8603bd9
commit
2715b6be9b
64
pep-3147.txt
64
pep-3147.txt
|
@ -355,12 +355,15 @@ didn't exist. This location of course includes the `__pycache__`
|
|||
subdirectory in its path.
|
||||
|
||||
For alternative Python implementations which do not support `pyc`
|
||||
files, the `__cached__` attribute may point to whatever
|
||||
version-specific binary file was read for the module code. E.g. on
|
||||
Jython, this might be the `.class` file for the module:
|
||||
`__pycache__/foo.jython-32.class`. Alternative implementations for
|
||||
which this scheme does not make sense should set the `__cached__`
|
||||
attribute to `None`.
|
||||
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 files compiled files to create the module, in which case
|
||||
`__cached__` may be a tuple. The exact contents of `__cached__` are
|
||||
Python implementation specific.
|
||||
|
||||
Alternative implementations for which this scheme does not make sense
|
||||
should set the `__cached__` attribute to `None`.
|
||||
|
||||
|
||||
File extension checks
|
||||
|
@ -475,6 +478,55 @@ guarantee that the pure-Python implementation and the built-in
|
|||
implementation remain in sync.
|
||||
|
||||
|
||||
Open issues
|
||||
===========
|
||||
|
||||
bytecode-only packages
|
||||
----------------------
|
||||
|
||||
Some users of Python distribute packages containing only the byte code
|
||||
files (pyc). The use cases for this are to make it more difficult for
|
||||
end-users to view the source code, and to reduce maintenance burdens
|
||||
when end users casually edit the source files.
|
||||
|
||||
This PEP currently promote no default support for bytecode-only
|
||||
packages. The primary motivator for this are that we can reduce stat
|
||||
calls if the importer only looks for .py files, making Python start-up
|
||||
and import faster.
|
||||
|
||||
The question is how to balance the requirements of bytecode-only users
|
||||
with the more universally beneficial faster start up times for
|
||||
requiring source files? Should all Python users pay the extra stat
|
||||
call penalty in the general case for a minority use case by default?
|
||||
|
||||
There are several ways out of this. Should we decide that it's
|
||||
important enough to support bytecode-only packages, the semantics
|
||||
would be as follows:
|
||||
|
||||
* If there is a traditional, non-magic-tagged .pyc file in the
|
||||
location where a .py file should be found, it will satisfy the
|
||||
import.
|
||||
* The `__file__` attribute of the module will point to the .pyc file.
|
||||
* The `__cached__` attribute of the module will point to the .pyc file
|
||||
too.
|
||||
* The existence of a matching `__pycached__/foo.<magic>.pyc` file
|
||||
without the source py file will *not* satisfy the import. This
|
||||
means that if the source file is removed, the pyc file will be
|
||||
ignored (unlike in today's implementation).
|
||||
|
||||
Other ways to satisfy the bytecode-only packagers requirements would
|
||||
have less impact on the general Python user population, and include:
|
||||
|
||||
* Add a `-X` switch and/or environment variable to enable
|
||||
the bytecode-only search algorithm.
|
||||
* Let those who want more protection against casual py hackers package
|
||||
their code in a zip file, which is supported today.
|
||||
* Provide a custom importer supporting bytecode-only packages, which
|
||||
would have to be enabled explicitly by the application. Either
|
||||
Python would provide such a custom importer or it would be left to
|
||||
third parties to implement.
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
|
|
Loading…
Reference in New Issue