traverseda
/
cpython
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

merge with 3.3

This commit is contained in:
Georg Brandl 2013-10-12 19:13:38 +02:00
parent a636c8e150 5db7c54f96
commit b9e8712a54
1 changed files with 32 additions and 44 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

76
Doc/tutorial/modules.rst
View File

@ -183,57 +183,45 @@ directory. This is an error unless the replacement is intended. See section
"Compiled" Python files "Compiled" Python files
----------------------- -----------------------
As an important speed-up of the start-up time for short programs that use a lot To speed up loading modules, Python caches the compiled version of each module
of standard modules, if a file called :file:`spam.pyc` exists in the directory in the ``__pycache__`` directory under the name :file:`module.{version}.pyc``,
where :file:`spam.py` is found, this is assumed to contain an where the version encodes the format of the compiled file; it generally contains
already-"byte-compiled" version of the module :mod:`spam`. The modification time the Python version number. For example, in CPython release 3.3 the compiled
of the version of :file:`spam.py` used to create :file:`spam.pyc` is recorded in version of spam.py would be cached as ``__pycache__/spam.cpython-33.pyc``. This
:file:`spam.pyc`, and the :file:`.pyc` file is ignored if these don't match. naming convention allows compiled modules from different releases and different
versions of Python to coexist.
Normally, you don't need to do anything to create the :file:`spam.pyc` file. Python checks the modification date of the source against the compiled version
Whenever :file:`spam.py` is successfully compiled, an attempt is made to write to see if it's out of date and needs to be recompiled. This is a completely
the compiled version to :file:`spam.pyc`. It is not an error if this attempt automatic process. Also, the compiled modules are platform-independent, so the
fails; if for any reason the file is not written completely, the resulting same library can be shared among systems with different architectures.
:file:`spam.pyc` file will be recognized as invalid and thus ignored later. The
contents of the :file:`spam.pyc` file are platform independent, so a Python Python does not check the cache in two circumstances. First, it always
module directory can be shared by machines of different architectures. recompiles and does not store the result for the module that's loaded directly
from the command line. Second, it does not check the cache if there is no
source module. To support a non-source (compiled only) distribution, the
compiled module must be in the source directory, and there must not be a source
module.
Some tips for experts: Some tips for experts:
* When the Python interpreter is invoked with the :option:`-O` flag, optimized * You can use the :option:`-O` or :option:`-OO` switches on the Python command
code is generated and stored in :file:`.pyo` files. The optimizer currently to reduce the size of a compiled module. The ``-O`` switch removes assert
doesn't help much; it only removes :keyword:`assert` statements. When statements, the ``-OO`` switch removes both assert statements and __doc__
:option:`-O` is used, *all* :term:`bytecode` is optimized; ``.pyc`` files are strings. Since some programs may rely on having these available, you should
ignored and ``.py`` files are compiled to optimized bytecode. only use this option if you know what you're doing. "Optimized" modules have
a .pyo rather than a .pyc suffix and are usually smaller. Future releases may
change the effects of optimization.
* Passing two :option:`-O` flags to the Python interpreter (:option:`-OO`) will * A program doesn't run any faster when it is read from a ``.pyc`` or ``.pyo``
cause the bytecode compiler to perform optimizations that could in some rare file than when it is read from a ``.py`` file; the only thing that's faster
cases result in malfunctioning programs. Currently only ``__doc__`` strings are about ``.pyc`` or ``.pyo`` files is the speed with which they are loaded.
removed from the bytecode, resulting in more compact :file:`.pyo` files. Since
some programs may rely on having these available, you should only use this
option if you know what you're doing.
* A program doesn't run any faster when it is read from a :file:`.pyc` or * The module :mod:`compileall` can create .pyc files (or .pyo files when
:file:`.pyo` file than when it is read from a :file:`.py` file; the only thing :option:`-O` is used) for all modules in a directory.
that's faster about :file:`.pyc` or :file:`.pyo` files is the speed with which
they are loaded.
* When a script is run by giving its name on the command line, the bytecode for * There is more detail on this process, including a flow chart of the
the script is never written to a :file:`.pyc` or :file:`.pyo` file. Thus, the decisions, in PEP 3147.
startup time of a script may be reduced by moving most of its code to a module
and having a small bootstrap script that imports that module. It is also
possible to name a :file:`.pyc` or :file:`.pyo` file directly on the command
line.
* It is possible to have a file called :file:`spam.pyc` (or :file:`spam.pyo`
when :option:`-O` is used) without a file :file:`spam.py` for the same module.
This can be used to distribute a library of Python code in a form that is
moderately hard to reverse engineer.
.. index:: module: compileall
* The module :mod:`compileall` can create :file:`.pyc` files (or :file:`.pyo`
files when :option:`-O` is used) for all modules in a directory.
.. _tut-standardmodules: .. _tut-standardmodules: