If you quit from the Python interpreter and enter it again, the definitions you have made (functions and variables) are lost. Therefore, if you want to write a somewhat longer program, you are better off using a text editor to prepare the input for the interpreter and running it with that file as input instead. This is known as creating a script. As your program gets longer, you may want to split it into several files for easier maintenance. You may also want to use a handy function that you've written in several programs without copying its definition into each program.
To support this, Python has a way to put definitions in a file and use them in a script or in an interactive instance of the interpreter. Such a file is called a module; definitions from a module can be imported into other modules or into the main module (the collection of variables that you have access to in a script executed at the top level and in calculator mode).
A module is a file containing Python definitions and statements. The
file name is the module name with the suffix .py appended. Within
a module, the module's name (as a string) is available as the value of
the global variable __name__. For instance, use your favorite text
editor to create a file called fibo.py in the current directory
with the following contents:
Now enter the Python interpreter and import this module with the following command:
This does not enter the names of the functions defined in fibo
directly in the current symbol table; it only enters the module name
fibo there.
Using the module name you can access the functions:
If you intend to use a function often you can assign it to a local name:
A module can contain executable statements as well as function
definitions.
These statements are intended to initialize the module.
They are executed only the
first time the module is imported somewhere.6.1 its
functions,
Modules can import other modules. It is customary but not required to
place all import statements at the beginning of a module (or
script, for that matter). The imported module names are placed in the
importing module's global symbol table.
There is a variant of the import statement that imports
names from a module directly into the importing module's symbol
Each module has its own private symbol table, which is used as the global symbol table by all functions defined in the module. Thus, the author of a module can use global variables in the module without worrying about accidental clashes with a user's global variables. On the other hand, if you know what you are doing you can touch a module's global variables with the same notation used to refer to
table. For example:
This does not introduce the module name from which the imports are taken
in the local symbol table (so in the example,
There is even a variant to import all names that a module defines:
This imports all names except those beginning with an underscore
(
When a module named spam is imported, the interpreter searches
for a file named spam.py in the current directory,
and then in the list of directories specified by
the environment variable PYTHONPATH. This has the same syntax as
the shell variable PATH, that is, a list of
directory names. When PYTHONPATH is not set, or when the file
is not found there, the search continues in an installation-dependent
path; on Unix, this is usually .:/usr/local/lib/python.
Actually, modules are searched in the list of directories given by the
variable
6.1.2 ``Compiled'' Python files
As an important speed-up of the start-up time for short programs that
use a lot of standard modules, if a file called spam.pyc exists
in the directory where spam.py is found, this is assumed to
contain an already-``byte-compiled'' version of the module spam.
The modification time of the version of spam.py used to create
spam.pyc is recorded in spam.pyc, and the
.pyc file is ignored if these don't match.
Normally, you don't need to do anything to create the
spam.pyc file. Whenever spam.py is successfully
compiled, an attempt is made to write the compiled version to
spam.pyc. It is not an error if this attempt fails; if for any
reason the file is not written completely, the resulting
spam.pyc file will be recognized as invalid and thus ignored
later. The contents of the spam.pyc file are platform
independent, so a Python module directory can be shared by machines of
different architectures.
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 amoeba module is only provided on systems that somehow
support Amoeba primitives. One particular module deserves some
attention: module-syssys, which is built into every
Python interpreter. The variables
These two variables are only defined if the interpreter is in
interactive mode.
The variable
The built-in function dir() is used to find out which names
a module defines. It returns a sorted list of strings:
Without arguments, dir() lists the names you have defined
currently:
Note that it lists all types of names: variables, modules, functions, etc.
dir() does not list the names of built-in functions and
variables. If you want a list of those, they are defined in the
standard module __builtin__:
Packages are a way of structuring Python's module namespace
by using ``dotted module names''. For example, the module name
A.B designates a submodule named "Bin a package named
"A. Just like the use of modules saves the authors of different
modules from having to worry about each other's global variable names,
the use of dotted module names saves the authors of multi-module
packages like NumPy or the Python Imaging Library from having to worry
about each other's module names.
Suppose you want to design a collection of modules (a ``package'') for
the uniform handling of sound files and sound data. There are many
different sound file formats (usually recognized by their extension,
for example: .wav, .aiff, .au), so you may need
to create and maintain a growing collection of modules for the
conversion between the various file formats. There are also many
different operations you might want to perform on sound data (such as
mixing, adding echo, applying an equalizer function, creating an
artificial stereo effect), so in addition you will be writing a
never-ending stream of modules to perform these operations. Here's a
possible structure for your package (expressed in terms of a
hierarchical filesystem):
When importing the package, Python searches through the directories
on
The __init__.py files are required to make Python treat the
directories as containing packages; this is done to prevent
directories with a common name, such as "string, from
unintentionally hiding valid modules that occur later on the module
search path. In the simplest case, __init__.py can just be an
empty file, but it can also execute initialization code for the
package or set the
Users of the package can import individual modules from the
package, for example:
This loads the submodule Sound.Effects.echo. It must be referenced
with its full name.
An alternative way of importing the submodule is:
This also loads the submodule echo, and makes it available without
its package prefix, so it can be used as follows:
Yet another variation is to import the desired function or variable directly:
Again, this loads the submodule echo, but this makes its function
echofilter() directly available:
Note that when using
Bhopal newsmodname.itemname.
fibo is not
defined).
_).
6.1.1 The Module Search Path
sys.path which is initialized from the directory
containing the input script (or the current directory),
PYTHONPATH and the installation-dependent . This allows
Python programs that know what they're doing to modify or replace the
module search path. Note that because the directory containing the
script being run is on the search path, it is important that the
script not have the same name as a standard module, or Python will
attempt to load the script as a module when that module is imported.
This will generally be an error. See section standardModules6.2,
``Standard Modules,'' for more information.
.pyc files are ignored and .py
files are compiled to optimized bytecode.
__doc__ strings are removed from the
bytecode, resulting in more compact .pyo files. Since some
programs may rely on having these available, you should only use this
option if you know what you're doing.
6.2 Standard Modules
sys.ps1 and
sys.ps2 define the strings used as primary and secondary
prompts:
sys.path is a list of strings that determine the
interpreter's search path for modules. It is initialized to a
path taken from the environment variable PYTHONPATH, or from
a built-in if PYTHONPATH is not set. You can modify
it using standard list operations:
6.3 The dir() Function
6.4 Packages
sys.path looking for the package subdirectory.
__all__ variable, described later.
from package import item, the
item can be either a submodule (or subpackage) of the package, or some
other name defined in the package, like a function, class or
variable. The import statement first tests whether the item is
defined in the package; if not, it assumes it is a member
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100