So far, this chapter has presented modules as files containing pure Python code. However, modules loaded with import really fall into four general categories:
■ C or C++ extensions that have been compiled into shared libraries or DLLs
■ Packages containing a collection of modules
■ Built-in modules written in C and linked into the Python interpreter
When looking for a module (for example, foo), the interpreter searches each of the directories in sys.path for the following files (listed in search order):
1. A directory, foo, defining a package
2. foo.pyd, foo.so, foomodule.so, or foomodule.dll (compiled extensions)
3. foo.pyo (only if the -O or -OO option has been used)
5. foo.py (on Windows, Python also checks for .pyw files.)
Packages are described shortly; compiled extensions are described in Chapter 26, "Extending and Embedding Python." For .py files, when a module is first imported, it's compiled into bytecode and written back to disk as a .pyc file. On subsequent imports, the interpreter loads this precompiled bytecode unless the modification date of the .py file is more recent (in which case, the .pyc file is regenerated). .pyo files are used in conjunction with the interpreter's -O option. These files contain bytecode stripped of line numbers, assertions, and other debugging information. As a result, they're somewhat smaller and allow the interpreter to run slightly faster. If the -OO option is specified instead of -O, documentation strings are also stripped from the file.This removal of documentation strings occurs only when .pyo files are created—not when they're loaded. If none of these files exists in any of the directories in sys.path, the interpreter checks whether the name corresponds to a built-in module name. If no match exists, an ImportError exception is raised.
The automatic compilation of files into .pyc and .pyo files occurs only in conjunction with the import statement. Programs specified on the command line or standard input don't produce such files. In addition, these files aren't created if the directory containing a module's .py file doesn't allow writing (e.g., either due to insufficient permission or if it's part of a zip archive).The -B option to the interpreter also disables the generation of these files.
If .pyc and .pyo files are available, it is not necessary for a corresponding .py file to exist. Thus, if you are packaging code and don't wish to include source, you can merely bundle a set of .pyc files together. However, be aware that Python has extensive support for introspection and disassembly. Knowledgeable users will still be able to inspect and find out a lot of details about your program even if the source hasn't been provided. Also, be aware that .pyc files tend to be version-specific.Thus, a .pyc file generated for one version of Python might not work in a future release.
When import searches for files, it matches filenames in a case-sensitive manner— even on machines where the underlying file system is case-insensitive, such as on Windows and OS X (such systems are case-preserving, however).Therefore, import foo will only import the file foo.py and not the file FOO.PY. However, as a general rule, you should avoid the use of module names that differ in case only.
Was this article helpful?