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__.
In [3]:
# Fibonacci numbers module
from __future__ import print_function
def fib(n): # write Fibonacci series up to n
a, b = 0, 1
while b < n:
print(b,)
a, b = b, a+b
def fib2(n): # return Fibonacci series up to n
result = []
a, b = 0, 1
while b < n:
result.append(b)
a, b = b, a+b
return result
Now enter the Python interpreter and import this module with the following command:
In [5]:
import fibo
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:
In [6]:
fibo.fib(1000)
In [7]:
fibo.fib2(100)
Out[7]:
In [8]:
fibo.__name__
Out[8]:
If you intend to use a function often you can assign it to a local name:
In [9]:
fib = fibo.fib
fib(500)
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 name is encountered in an import statement.
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 its functions, modname.itemname.
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 table. For example:
In [10]:
from fibo import fib, fib2
fib(500)
This does not introduce the module name from which the imports are taken in the local symbol table (so in the example, fibo is not defined).
In [11]:
from fibo import *
fib(500)
This imports all names except those beginning with an underscore (_).
Note that in general the practice of importing * from a module or package is frowned upon, since it often causes poorly readable code.
However, it is okay to use it to save typing in interactive sessions.
In [12]:
import fibo, sys
print(dir(fibo))
In [13]:
print(dir(sys))
Without arguments, dir() lists the names you have defined currently:
In [14]:
a = [1, 2, 3, 4, 5]
import fibo
fib = fibo.fib
print(dir())
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 builtins:
In [17]:
import builtins
print(dir(__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 B in 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):
sound/ Top-level package
__init__.py Initialize the sound package
formats/ Subpackage for file format conversions
__init__.py
wavread.py
wavwrite.py
aiffread.py
aiffwrite.py
auread.py
auwrite.py
...
effects/ Subpackage for sound effects
__init__.py
echo.py
surround.py
reverse.py
...
filters/ Subpackage for filters
__init__.py
equalizer.py
vocoder.py
karaoke.py
...