Chapter 6. Modules 44 Python Tutorial  Release 3.9.5 6.2 Standard Modules 6.1.3 “Compiled” Python files To speed up loading modules  Python caches the compiled version of each module in the$_{__pycache__}$ directory under the name$_{module.}$ version .pyc   where the version encodes the format of the compiled file; it generally contains the Python version number. For example  in CPython release 3.3 the compiled version of spam.py would be cached as __pycache__/spam.cpython-33.pyc . This naming convention allows compiled modules from different releases and different versions of Python to coexist. Python checks the modification date of the source against the compiled version to see if it’s out of date and needs to be recompiled. This is a completely automatic process. Also  the compiled modules are platform-independent  so the same library can be shared among systems with different architectures. Python does not check the cache in two circumstances. First  it always 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: Python comes with a library of standard modules  described in a separate document  the Python Library Reference (“Library Reference” hereafter). Some modules are built into the interpreter; these provide access to operations that are not part of the core of the language but are nevertheless built in  either for efficiency or to provide access to operating system primitives such as system calls. The set of such modules is a configuration option which also depends on the underlying platform. For example  the$_{winreg}$ module is only provided on Windows systems. One particular module deserves some attention: $_{sys}$  which is built into every Python interpreter. The variables$_{sys.ps1}$ and sys.ps2 define the strings used as primary and secondary prompts: These two variables are only defined if the interpreter is in interactive mode. The variable$_{sys.path}$is a list of strings that determines the interpreter’s search path for modules. It is initialized to a default path taken from the environment variable$_{PYTHONPATH}$   or from a built-in default if$_{PYTHONPATH}$ is not set. You can modify it using standard list operations: >>> import sys >>> sys.path.append( '/ufs/guido/lib/python ') >>> import sys >>> sys.ps1 '>>> ' >>> sys.ps2 '... ' >>> sys.ps1='C>' C> print('Yuck!') Yuck! C> • There is more detail on this process  including a flow chart of the decisions  in PEP 3147 • The module$_{compileall}$ can create .pyc files for all modules in a directory. • A program doesn’t run any faster when it is read from a$_{.pyc}$ file than when it is read from a$_{.py}$file; the only thing that’s faster about$_{.pyc}$ files is the speed with which they are loaded. • You can use the$_{-O}$or$_{-OO}$switches on the Python command to reduce the size of a compiled module. The$_{-O}$ switch removes assert statements  the -OO switch removes both assert statements and __doc__ strings. Since some programs may rely on having these available  you should only use this option if you know what you’re doing. “Optimized” modules have an$_{opt-}$ tag and are usually smaller. Future releases may change the effects of optimization.