Chapter 6 Module
If you exit the Python interpreter and then enter, the original definition (functions and variables) will be lost. Therefore, if you need to write a longer program, it is best to use a text editing program to prepare input for the interpreter, and then run the Python interpreter with the program file as input. This is called a preparation script. When your program gets longer, it is best to split it into several files for maintenance. You may also want to use a very convenient function in several programs, but you do not want to assign function definitions to each program.
To support these, Python has a way to put the definition in a file and then call it in a script or in an interactive run. Such a file is called a module; the definitions in the module can be imported into other modules or main modules (the main module refers to a collection of variables that can be accessed by scripts executed at the top level of the program or programs executed interactively).
A module is a file containing Python definitions and statements. The file name consists of the module name plus the suffix ".py". Within a module, the name of the module (as a string) can be known by the value of the global variable __name__. For example, in the Python search path, use the text editor you are used to using (Python 1.5.2 contains an IDLE integrated development environment written in Tkinter, and there is a PythonWin interface under MS Windows that can also be edited by Python programs) to generate a file named " ", which contains the following content:
# Fibonacci numbers module
def fib(n): # Output a Fibonacci sequence smaller than n
a, b = 0, 1
while b < n:
print b,
a, b = b, a+b
def fib2(n): # Returns a Fibonacci sequence smaller than n
result = []
a, b = 0, 1
while b < n:
(b)
a, b = b, a+b
return result
Then enter the Python interpreter (you can directly enter the interpreter window in IDLE or PythonWin), and use the following command to import the module:
>>> import fibo
This will not directly introduce the name of the function in the module fibo into the current symbol table, it will only introduce the module name fibo. You can access the functions in the module name:
>>> (1000)
1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987
>>> fibo.fib2(100)
[1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89]
>>> fibo.__name__
'fibo'
If you use a function frequently, you can assign it a local name:
>>> fib =
>>> fib(500)
1 1 2 3 5 8 13 21 34 55 89 144 233 377
6.1 Further introduction to modules
A module can also contain executable statements in addition to function definitions. These executable statements are used to initialize modules and they are executed only when the module is first imported.
Each module has its own private symbol table, which is their global symbol table for all functions in the module. Therefore, module authors can use global variables in modules without worrying about conflicts with module users. On the other hand, if you are sure, you can also use the method of accessing the format of the function in the module, i.e. to modify the global variables in the module.
Modules can be imported into other modules. We usually place all import statements at the beginning of the module (or script), which is not required. The imported module name is placed in the module's global symbol table.
There is another usage for importing, which can directly import the names in the module into the user's symbol table. For example:
>>> from fibo import fib, fib2
>>> fib(500)
1 1 2 3 5 8 13 21 34 55 89 144 233 377
This does not import the module name into the user's symbol table (for example, fibo is not defined in the above example).
There is also a way to import all names defined in a module:
>>> from fibo import *
>>> fib(500)
1 1 2 3 5 8 13 21 34 55 89 144 233 377
This can import all names in the module except the end of the underscore.
6.1.1 Module search path
When importing a module named spam, the interpreter first looks for a file named "" in the current directory, and then looks for a list of directories defined by the environment variable PYTHONPATH. The usage of PYTHONPATH is the same as the search path of the executable file, and both are a directory list. When PYTHONPATH is not set, or the file is still not found, the search continues to search for the default path set during installation. In Unix, this is usually ".:/usr/local/lib/python".
In fact, the module is searched by the path specified by the variable, which is initialized at the interpreter startup to the directory (or current path), PYTHONPATH, and installation default path. In this way, users can modify and replace module search paths by modifying. See the following section on standard modules.
6.1.2 "Compiled" Python files
In order to increase the startup time of applets that call many standard modules, an important measure is that if there is a file named "" in the directory where "" is found, it is considered that this file contains a so-called "byte compiled" version of the module spam. The modification time used to generate "" is recorded in "", and if the recorded modification time does not match the current file time, the compiled file will be ignored.
Generally, you don't need to generate a compiled file like "" by yourself. Whenever the "" is successfully compiled, the interpreter tries to write the compiled version "", and there will be no error if it is not written; if the file is not finished because of some reason, the generated "" is recognized as incomplete and ignored. The format of the compiled file "" is platform-dependent, so machines with different structures can share the Python module directory.
Here are some tips for experts:
If the Python interpreter is started with the -O flag, the optimized compiled code will be generated and saved in the ".pyo" file. There are not many optimizations at present, and now we just remove the assert statement and the SET_LINENO instruction. When the -O flag is used, all bytecodes are optimized, the ".pyc" file is ignored, and the ".py" file is compiled into the optimized bytecode.
The optimization code generated by interpreting the program two optimization flags (-OO) in Python can sometimes cause the program to run abnormally. Currently, the dual optimization only removes the __doc__ string from the bytecode, making the ".pyo" file smaller. Some programs may rely on document strings, so this optimization can only be used if you know there will be no problems.
Programs read from ".pyc" or ".pyo" cannot run faster than those read from ".py", they just call in faster.
If a program is run in a way that specifies the script file name on the command line, the script's bytecode will not be written to the ".pyc " or ".pyo" file. Therefore, if the main code of the program is moved into one module, and only the bootloader that imports the module is left in the script, the script can be slightly shortened.
There can be a file called "" (when the -O flag is used) without the corresponding source file "". This can be used to distribute a Python code base that is more difficult to decompile.
Module compileall can compile all modules in a directory into ".pyc" files (compile as ".pyo" files when the -O option is specified).
6.2 Standard module
Python comes with a standard module library, which is described in another document, "Python Library Reference". Some modules are directly incorporated into the interpreter program. These modules are not the core of the language. They are incorporated into the interpreter program for operational efficiency or to provide underlying system functions such as system calls. Providing those modules is a compile-time option, for example, the amoeba module can only be provided in systems that provide the amoeba underlying instructions.
There is a module worthy of special attention: the sys module, which is compiled into every Python interpreter. The variables sys.ps1 and sys.ps2 define the initial prompt and continuous prompt during interactive runtime.
>>> import sys
>>> sys.ps1
'>>> '
>>> sys.ps2
'... '
>>> sys.ps1 = 'C> '
C> print 'Yuck!'
Yuck!
C>
These two variables are defined only when the interpreter runs interactively.
A variable is a list of strings that determines the module search path of the interpreter. It is initialized as the default path specified by the environment variable PYTHONPATH, and the environment variable is initialized as the default path at installation when it is not defined. This search path can be modified using standard list operations, for example:
>>> import sys
>>> ('/ufs/guido/lib/python')
6.3 dir() function
The built-in function dir() is used to list the name defined by a module, which returns a list of strings:
>>> import fibo, sys
>>> dir(fibo)
['__name__', 'fib', 'fib2']
>>> dir(sys)
['__name__', 'argv', 'builtin_module_names', 'copyright', 'exit',
'maxint', 'modules', 'path', 'ps1', 'ps2', 'setprofile', 'settrace',
'stderr', 'stdin', 'stdout', 'version']
When there are no arguments, dir() lists the currently defined name.
>>> a = [1, 2, 3, 4, 5]
>>> import fibo, sys
>>> fib =
>>> dir()
['__name__', 'a', 'fib', 'fibo', 'sys']
Note that dir() lists all types of names: variable names, module names, function names, etc. dir() will not list the names of built-in functions and variables. To list built-in names, you need to use the standard module __builtin__:
>>> import __builtin__
>>> dir(__builtin__)
['AccessError', 'AttributeError', 'ConflictError', 'EOFError', 'IOError',
'ImportError', 'IndexError', 'KeyError', 'KeyboardInterrupt',
'MemoryError', 'NameError', 'None', 'OverflowError', 'RuntimeError',
'SyntaxError', 'SystemError', 'SystemExit', 'TypeError', 'ValueError',
'ZeroDivisionError', '__name__', 'abs', 'apply', 'chr', 'cmp', 'coerce',
'compile', 'dir', 'divmod', 'eval', 'execfile', 'filter', 'float',
'getattr', 'hasattr', 'hash', 'hex', 'id', 'input', 'int', 'len', 'long',
'map', 'max', 'min', 'oct', 'open', 'ord', 'pow', 'range', 'raw_input',
'reduce', 'reload', 'repr', 'round', 'setattr', 'str', 'type', 'xrange']
6.4 Package
In Python, "package" can be used to organize Python's module name space. When referencing names, "dotted module names can be used. For example, the module name represents a submodule named "B" in package "A". Just as using modules can make authors of different modules not worry about conflicting global variable names, using dotted module names can make authors of multiple module packages such as NumPy and PIL do not need to worry about conflicting module names.
Suppose you have a series of modules (called a "package") that handle sound files and sound data. There are many different sound file formats (usually identified with extensions such as "wav", ".aiff", ".au"), so you may need to make and maintain an ever-increasing set of modules to handle conversions in different file formats. You may also need to do many different operations on the sound data (such as mixing, echoing, equalizing, producing analog stereo effects), so you also need to continue to add modules to perform these operations. Here is the possible structure of your package (denoted by a hierarchical file system):
Sound/
__init__.py
Formats/ Subpackage for file format conversion
__init__.py
...
Effects/
__init__.py
...
Filters/
__init__.py
...
The "__init__.py" file in the package directory is a must-have to instruct Python to regard this directory as a package, which can prevent subdirectories with the same name such as "string" from covering up some module definitions that appear behind the search path. In the simplest case, "__init__.py" can be an empty file, it can also contain the code needed to initialize the package and set the "__all__" variable, which will be discussed later.
The user of the package can import separate modules from the package, such as:
import
This allows you to import the submodule. To quote it, you must also use the full name, for example:
(input, output, delay=0.7, atten=4)
Another way to import submodules is:
from import echo
This also imports submodule echo, but does not require a package prefix to be written when calling, so you can use:
(input, output, delay=0.7, atten=4)
Another way to write it is to directly import the required functions or variables:
from import echofilter
This time, the submodule echo is also called, but the function echofilter is directly available:
echofilter(input, output, delay=0.7, atten=4)
Note that when using the format "from package import item", the imported item can be a submodule (or subpackage) of the package, or other names defined in the package, such as functions, classes, and variables. The import statement first looks for whether the required item is defined in the package, and if not, assume it is a module and then call it in. If not found, the result causes an ImportError.
On the contrary, when using a format like "import ", all other items except the last one should be packages. The last item can be a package or a module. It is not allowed to be classes, functions or variables internally defined by the previous item.
6.4.1 Import from package*
Now, what happens if the user writes "from import *"? Ideally we hope this should scan the file system, find all the submodules inside the package and import them all in. Unfortunately, this operation cannot be implemented accurately on Mac and Windows platforms, and these two operating systems do not have accurate information on the case of file names. On these platforms, it is not known that the file named "" will be imported as module echo, Echo or ECHO. (For example, Windows 95 always capitalizes the first letter when displaying file names). The 8+3 file name limit of DOS has caused interesting difficulties for long module names.
The only solution to this problem is to explicitly provide the index of the package by the module author. The import statement that introduces * follows the following provisions: If the package's "__init__.py" file defines a list called "__all__", this list is used as the name list of all modules to be imported when importing * from the package. Therefore, when a new version of the package is released, the author of the package needs to make sure that this list is up to date. If the author of the package believes that it does not require importing*, this usage may not be supported. For example, the file Sounds/Effects/__init__.py can contain the following code:
__all__ = ["echo", "surround", "reverse"]
This means from import * will import the specified three subpackages from the Sound package.
If __all__ is not defined, the from import * statement will not import all submodules in the package; this statement can only be guaranteed to be imported (maybe executing its initialization code "__init__.py ") and importing the name directly defined in the package. This includes any name defined by "__init__.py" and explicitly imported submodule names. This also includes submodules in the module that have been explicitly imported with import in the previous module, for example:
import
import
from import *
In this example, the echo and surround modules are imported into the current namespace because they are defined when executing the from...import statement (this also holds true if __all__ is defined).
Note that users should try to avoid importing * from modules or packages, as this often leads to poor readability of code. Nevertheless, the import* method can be used to save key-ticking times when running interactively, and some modules have this problem in mind when designing, and they only output names that follow certain conventions. Note that there is nothing wrong with the usage of the from package import specific submodules. In fact, this is still the recommended usage, unless the program also needs to use submodules of the same name from other packages.
6.4.2 Internal references of packages
Submodules often need to be referenced to each other. For example, module surround may use module echo. In fact, such references are very common, so the import statement first looks for the submodule to be imported from the package of the submodule and then looks for the standard module search path. Therefore, the module surround only needs to write import echo or from echo import echofilter. If the module to be imported is not found in the package containing this module, the import statement will look for the top-level module with the specified name.
When a package is organized into a subpackage (such as the Sound package in the example), there is no simple way to refer to a submodule in a sibling package - the full name of the submodule must be used. For example, if the module wants to reference the echo module in the package, it can use import echo.
Previous page12345678910Next pageRead the full text