15.2 Python Program Architecture

So far in this book, we've sugar-coated some of the complexity in our descriptions of Python programs. In practice, programs usually are more than just one file; for all but the simplest scripts, your programs will take the form of multifile systems. And even if you can get by with coding a single file yourself, you will almost certainly wind up using external files that someone else has already written.

This section introduces the general architecture of Python programs—the way you divide a program into a collection of source files (a.k.a. modules), and link the parts into a whole. Along the way, we also define the central concepts of Python modules, imports, and object attributes.

15.2.1 How to Structure a Program

Generally, a Python program consists of multiple text files containing Python statements. The program is structured as one main, top-level file, along with zero or more supplemental files known as modules in Python.

In a Python program, the top-level file contains the main flow of control of your program—the file you run to launch your application. The module files are libraries of tools, used to collect components used by the top-level file, and possibly elsewhere. Top-level files use tools defined in module files, and modules use tools defined in other modules. In Python, a file imports a module to gain access to the tools it defines. And the tools defined by a module are known as its attributes—variable names attached to objects such as functions. Ultimately, we import modules, and access their attributes to use their tools.

15.2.2 Imports and Attributes

Let's make this a bit more concrete. Figure 15-1 sketches the structure of a Python program composed of three files: a.py, b.py, and c.py. The file a.py is chosen to be the top-level file; it will be a simple text file of statements, which is executed from top to bottom when launched. Files b.py and c.py are modules; they are simple text files of statements as well, but are usually not launched directly. Rather, modules are normally imported by other files that wish to use the tools they define.

Figure 15-1. Program architecture

For instance, suppose file b.py in Figure 15-1 defines a function called spam, for external use. As we learned in Part IV, b.py would contain a Python def statement to generate the function, which is later run by passing zero or more values in parenthesis after the function's name:

def spam(text):
    print text, 'spam'

Now, if a.py wants to use spam, it might contain Python statements such as the following:

import b
b.spam('gumby')

The first of these two, a Python import statement, gives file a.py access to everything defined in file b.py. It roughly means: "load file b.py (unless it's already loaded), and give me access to all its attributes through name b." import (and as you'll see later, from) statements execute and load another file at runtime. In Python, cross-file module linking is not resolved until such import statements are executed.

The second of these statements calls the function spam defined in module b using object attribute notation. The code b.spam means: "fetch the value of name spam that lives within object b." This happens to be a callable function in our example, so we pass a string in parenthesis ('gumby'). If you actually type these files and run a.py, the words "gumby spam" are printed.

More generally, you'll see the notation object.attribute throughout Python scripts—most objects have useful attributes that are fetched with the "." operator. Some are callable things like functions, and others are simple data values that give object properties (e.g., a person's name).

The notion of importing is also general throughout Python. Any file can import tools from any other file. For instance, file a.py may import b.py to call its function, but b.py might also import c.py in order to leverage different tools defined there. Import chains can go as deep as you like: in this example, module a can import b, which can import c, which can import b again, and so on.

Besides serving as a highest organization structure, modules (and module packages, described in Chapter 17) are also the highest level of code reuse in Python. By coding components in module files, they become useful in both the original program, as well as in any other program you may write. For instance, if after coding the program in Figure 15-1 we discover that function b.spam is a general purpose tool, we can reuse it in a completely different program; simply import file b.py again, from the other program's files.

15.2.3 Standard Library Modules

Notice the rightmost portion of Figure 15-1. Some of the modules that your programs will import are provided by Python itself, not files you will code. Python automatically comes with a large collection of utility modules known as the Standard Library .

This collection, roughly 200 modules large at last count, contains platform independent support for common programming tasks: operating system interfaces, object persistence, text pattern matching, network and Internet scripting, GUI construction, and much more. None of these are part of the Python language itself, but can be used by importing the appropriate modules on any standard Python installation.

In this book, you will meet a few of the standard library modules in action in the examples, but for a complete look, you should browse the standard Python Library Reference Manual, available either with your Python installation (they are in IDLE and your Python Start button entry on Windows), or online at http://www.python.org.

Because there are so many modules, this is really the only way to get a feel for what tools are available. You can also find Python library materials in commercial books, but the manuals are free, viewable in any web browser (they ship in HTLM format), and updated each time Python is re-released.