This appendix provides additional installation and configuration details, as a resource for people new to such topics.
Because you need the Python interpreter to run Python scripts, your first step to using Python is usually installing Python. Unless a Python is already available on your machine, you’ll need to fetch, install, and possibly configure a Python on your computer. You only need to do this once per machine, and perhaps not at all, if you will be running a frozen binary.
First off, before doing anything, make sure you
don’t already have a recent Python on your machine.
For instance, if you are working on Linux, or some Unix systems,
Python is probably already installed. Type
python
at a shell prompt and see what happens;
alternatively, try searching the usual places
(/usr/bin, /usr/local/bin,
etc.). On Windows, check if there is a Python entry in the programs
menu you find in your Start button, at the bottom left of the screen.
Make sure the Python you find is version 2.2 or later;
you’ll need that to run some of the examples in this
edition.
If there is no Python to be found, you will need to install one yourself. You can always fetch the latest and greatest standard Python release from http://www.python.org, Python’s official web site; look for the Downloads link on that page, and grab a release for the platform you will be working on. There, you’ll find prebuilt Python executables (unpack and run); self-installer executables for Windows (click to install); RPMs for Linux (unpack with rpm); the full source-code distribution (compile on your machine to generate an interpreter); and more. For some platforms such as PalmOS and PocketPC, Python’s web site links to an offsite page where these versions are maintained.
You can also find Python on CD-ROMs supplied with Linux distributions, included with some products and computer systems, sold by commercial outlets such as Dr. Dobb’s Journal, and enclosed with other Python books. These tend to lag behind the current release somewhat, but usually not seriously so.
In addition, a company called ActiveState also distributes Python, as part of its ActivePython package. This package combines standard CPython with extensions for Windows development, an IDE called PythonWin (described in Chapter 3), and other commonly used extensions. See ActiveState’s web site, www.activestate.com, for more details on the ActivePython package.
Finally, if you are interested in alternative Python implementations, try www.jython.org for Jython, and AciveState’s web site for Python.NET; installation of these systems is beyond the scope of this book.
Once you have your Python, it must be installed. Installation steps are very platform-specific, but here are a few pointers for major Python platforms:
On Windows, Python comes as a self-installer executable program file—simply double-click on its file icon, and answer Yes or Next to every prompt, to perform a default install. The default install includes Python’s documentation set, and support for Tkinter GUIs, shelve databases, the IDLE development GUI, and other things we’ll describe later. After the install, Python shows up in the programs menu of your Start button.
Python’s menu has five entries that give quick access to common tasks: starting the IDLE user interface; reading module documentation; starting an interactive session; reading Python’s standard manuals in a web broswer; and uninstalling. Most of these actions involve concepts we explore in detail elsdewhere in this text.
When installed on Windows, Python also automatically registers itself to be the program that opens Python files when their icons are clicked—a program launch technique described in Chapter 3. It is also possible to build Python from its source-code on Windows, but this is not common.
On Linux, Python is available as one or more RPM files, which you unpack in the usual way. Consult your RPM man page for more details. Depending on which RPMs you download, there may be one for Python itself, and another that adds support for Tkinter GUIs and the IDLE environment. Since Linux is a Unix-like system, the next paragraph applies as well.
On Unix systems, Python is usually compiled from its full C
source-code distribution. This usually only requires unpacking the
file, and running simple config
and
make
commands; Python configures its own build
procedure automatically, according to the system it is being compiled
on. However, be sure to see the package’s
README file for more details on this process.
Because Python is Open Source, its source code may be used and
distributed free of charge.
On other platforms, these details can differ widely; installing the “Pippy” port of Python for the PalmOS, for example, requires a hot synch operation with your PDA, and Python for the Sharp Zaurus Linux-based PDA comes as one or more .ipk files, which you simply run to install. Because additional install procedures for both executable and source forms are well documented, though, we’ll skip further details here.
After you’ve installed Python, you can also configure system settings that impact the way Python runs your code. When you are just getting started with the language, you can probably skip this section completely; there is usually no need to make any system settings at all for basic programs.
Generally speaking, though, parts of the Python interpreter’s behaviour can be configured both with enironment variable settings, and command-line options. In this section, we take a brief look at Python environment variables. Python command-line options—words listed when you launch a Python program from a system prompt—are used more rarely, and have very specialized roles; see other documentation sources for Python’s command-line option details.
Environment variables—known to some as shell variables, or DOS variables—live outside Python, and thus can be used to customize the interpreter’s behavior each time it is run on a given computer. Python recognizes a handful of environment variable settings, but only a few are used often enough to warrant explanation here. Table A-1 summarizes the main Python-related environment variable settings.
Variable |
Role |
|
System shell search path (for finding “python”) |
|
Python module search path (for imports) |
|
Path to Python interactive startup file |
|
GUI extension variables (Tkinter) |
These variables are straightforward to use, but here are a few pointers:
The PATH
setting lists a set of directories that
the operating system searches for executable programs. It should
normally include the directory where your Python interpreter lives
(the python
program on Unix, or the
python.exe file on Windows). You
don’t need to set this variable at all, if you are
willing to either work in the directory where Python resides, or type
the full path to Python in command-lines. On Windows, for instance,
the PATH
is irrelevant if you run
cd
C:Python22
before running
any code (to change to the directory where Python lives), or always
type C:Python22python
instead of just
python
(to give a full path). Also note thet PATH
settings are mostly for launching programs from command lines; they
are usually irrelevent for running with icon clicks and IDEs.
The PYTHONPATH
setting serves a role similar to
PATH
: the Python interpreter consults the
PYTHONPATH
variable to locate module files when
you import them in a program. (We talked about the module search path
in Chapter 15.) If used, this variable is set to a
platform-dependent list of directory names, separated by colons on
Unix, and semicolons on Windows. This list normally includes just
your own source-code directories. You don’t need to
set this variable either, unless you will be performing
cross-directory imports—because Python always searches the home
directory of the program’s top-level file
automatically, this setting is only required if a module needs to
import another module that lives in a different directory. As
mentioned in Chapter 15, .pth
files are a recent alternative to PYTHONPATH
.
If PYTHONSTARTUP
is set to the pathname of a file of
Python code, Python executes the file’s code
automatically whenever you start the interactive interpreter, as
though you had typed it at the interactive command line. This is a
rarely used, but handy way to make sure you always load utilities
whenever working interactively; it saves an import.
If you wish to use
the Tkinter GUI toolkit, you might have
to set the two GUI variables in Table A-1 to the
name of the source library directories of the Tcl and Tk systems
(much like PYTHONPATH
). However, these settings
are not required on Windows systems (where Tkinter support is
installed alongside Python), and are usually not required elsewhere
if Tcl and Tk reside in standard directories.
Note that because these environment settings (as well as .pth files) are external to Python itself, the time at which you set these is usually irrelevant. They may be set before or after Python is installed—just as long as they are set the way you require before Python is actually run.
The way to set these variables, and what to set them to, depends on the type of computer you will work on. And again, remember that you don’t necessarily have to set these at all right away; especially when working under IDLE (described in Chapter 3), configuration is not required up-front.
But suppose, for illustration, that you have generally useful module files in directories called utilities and package1 somewhere on your machine, and you want to be able to import these modules from files located in any other directory. To load a file called spam.py from the utilities directory, you want to be able to say:
import spam
from another file located anywhere on your computer. To make this
work, you’ll have to configure your module search
path one way or another to imclude the directory contaiing
spam.py
. Here are a few tips on this process.
On Unix systems the way to set envoronment variables depends on the shell you use. Under the csh shell, you might add a line like the following in your .cshrc or .login file, to set the Python module search path:
setenv PYTHONPATH /usr/home/pycode/utilities:/usr/lib/pycode/package1
This tells Python to look for imported modules in two user-defined directories. But if you’re using the ksh shell, the setting might instead appear in your .kshrc file, and look like this:
export PYTHONPATH="/usr/home/pycode/utilities:/usr/lib/pycode/package1"
Other shells may use different, but analogous syntax.
If you are using MS-DOS or some older flavors of MS-Windows, you may need to add an environment variable configuration command to your C:autoexec.bat file, and reboot your machine for the changes to take effect. The configuration command on such machines would have a syntax unique to DOS:
set PYTHONPATH=c:pycodeutilities;d:pycodepackage1
You can type such a command in a DOS console window too, but the setting will then be active only for that one console window. Changing your .bat file makes the change permanent, and global to all programs.
On more recent versions of Windows, you may instead set
PYTHONPATH
and others by navigating to the system
environment variable GUI, without having to edit
files or reboot. On XP, select Control Panel, choose the System icon,
pick the Advanced tab, and click the Environment Variables button to
edit or add new variables (PYTHONPATH
is usually a
user variable). You do not need to reboot your machine, but be sure
to restart Python if open, so that it picks up your changes (it
configures its path at start-up time only).
If you are an experienced Windows user, you may also be able to
configure the module search path by using the Windows Registry
Editor. Type regedit
in the Run... option of
your Start button to see if the typical registry tool is on your
machine, and navigate to Python’s entries. This is a
delicate and error-prone procedure—unless
you’re familiar with the registry, we suggest other
options.
Finally, if you choose to extend the module search path with a
.pth file instead of the
PYTHONPATH
variable, you might instead code a text
file that looks like the following on Windows (file
C:Python22mypath.pth). Its contents will
differ per platform, and its container directory may differ per both
platform and Python release. Python locates this file automatically
when it starts up:
c:pycodeutilities d:pycodepackage1
Directory names in path files may be absolute, or relative to the directory containing the path file; multiple .pth files can be used (all their directories are added); and .pth files may appear in various automatically-checked directories that are platform and version-specific. For example, Release 2.2 typically looks for path files in C:Python22 and C:Python22Libsite-packages on Windows, and in /usr/local/lib/python2.2/site-packages and /usr/local/lib/site-python on Unix and Linux.
Because these settings are often optional, though, and because this isn’t a book on operating system shells, we’re going to defer to other sources for more details. Consult your system shell’s manpages or other documentation for details. And if you have trouble figuring out what your settings must be, ask your system administrator or other local expert for help.