Previous Page
Next Page

2.1. Installing Python from Source Code

To install CPython from source code, you need a platform with an ISO-compliant C compiler and ancillary tools such as make. On Windows, the normal way to build Python is with Microsoft Visual Studio (version 7.1, a.k.a. VS2003, for Python 2.4 and 2.5).

To download Python source code, visit and follow the link labeled Download. The latest version at the time of this writing is:

The .tgz file extension is equivalent to .tar.gz (i.e., a tar archive of files, compressed by the powerful and popular gzip compressor). You can also get a version with an extension of .tar.bz2 instead of .tgz, compressed with the even more powerful bzip2 compressor, if you're able to deal with Bzip-2 compression (most popular utilities can nowadays).

To download sources for Python 2.5, see At the same URL, you will also find Python 2.5 documentation and binary releases. At the time of this writing, the first alpha release of 2.5 had just appeared, but by the time you read this book the final release of 2.5 is likely to be available.

2.1.1. Windows

On Windows, installing Python from source code can be a chore unless you are already familiar with Microsoft Visual Studio and also used to working at the Windows command line (i.e., in the text-oriented windows known as MS-DOS Prompt or Command Prompt, depending on your version of Windows).

If the following instructions give you trouble, I suggest you skip ahead to "Installing Python from Binaries" on page 18. It may be a good idea to do an installation from binaries anyway, even if you also install from source code. This way, if you notice anything strange while using the version you installed from source code, you can double-check with the installation from binaries. If the strangeness goes away, it must be due to some quirk in your installation from source code, and then you know you must double-check the latter.

In the following sections, for clarity, I assume you have made a new directory named C:\Py and downloaded Python-2.4.3.tgz there. Of course, you can choose to name and place the directory as it best suits you. Uncompressing and unpacking the Python source code

You can uncompress and unpack a .tgz file with programs tar and gunzip. If you do not have tar and gunzip, you can download the collection of utilities into C:\Py. If you do not have other ways to unpack a ZIP file, download into C:\Py. Open an MS-DOS Prompt window and give the following commands:

C:\> My Documents> cd \Py
C:\Py> unzip winutils
    [unzip lists the files it is unpacking - omitted here]
C:\Py> gunzip Python-2.4.3.tgz
C:\Py> tar xvf Python-2.4.3.tar
    [tar lists the files it is unpacking - omitted here]

Many commercial programs, such as WinZip ( and PowerArchiver (, can also uncompress and unpack .tgz archives (and .tar.bz2 ones too). Whether via gunzip and tar, a commercial program, or some other program, you now have a directory C:\Py\Python-2.4.3, the root of a tree that contains the entire standard Python distribution in source form. Building the Python source code with Microsoft Visual Studio 2003

Open the workspace file C:\Py\Python-2.4.3\PCbuild\pcbuild.dsw with Microsoft Visual Studiofor example, by starting Windows Explorer, going to directory C:\Py\Python-2.4.3\PCbuild, and double-clicking on file pcbuild.dsw.

Choose Build Set Active Configuration python Win32 Release, and then choose Build Build python.exe. Visual Studio builds projects pythoncore and python, making files python24.dll and python.exe in C:\Py\Python-2.4.3\PCbuild. You can also build other subprojects (for example, with Build Batch Build...). To build subprojects _tkinter, bsddb, pyexpat, and zlib, you first need to download other open source packages and install them in the C:\Py directory. Follow the instructions in C:\Py\Python-2.4.3\PCbuild\readme.txt to build every Python package that is in the distribution. Building Python for debugging

You can also, optionally, build the debug versions, as well as the release versions, of the Python packages.

With Visual Studio, an executable (.exe) built for release can interoperate fully only with dynamic load libraries (DLLs) also built for release, while an executable built for debugging interoperates fully only with DLLs also built for debugging. Trying to mix and match can cause program crashes and assorted strangeness. To help you avoid accidentally mixing parts built for release with others built for debugging, the Python workspace appends a _d to the name of debugging executables and DLLs. For example, when you build for debugging, project pythoncore produces python24_d.dll and project python produces python24_d.exe.

What makes the debugging and release Visual Studio builds incompatible is the choice of C runtime library. Executables and DLLs can fully interoperate only by using the same C runtime library, and the runtime library must in turn be a DLL. You can tweak Project Settings C/C++ Code Generation Use run-time library, setting all projects to use Multithreaded DLL (MSVCRT.DLL) (also remove the _DEBUG definition in C/C++ Code Generation Preprocessor). I recommend you follow this approach only if you are highly experienced with Microsoft Visual Studio and have special, advanced requirements. Otherwise, resign yourself to keeping two separate and distinct release and debugging "worlds"; this is, by far, the simplest approach on Windows. Installing after the build

python24.dll (or python24_d.dll if you want to run a debug-mode python_d.exe) must be in a directory from which Windows loads DLLs when needed. Suitable directories depend on your version of Windows; for example, c:\windows\system is one possibility. If you don't copy python24.dll to such a suitable directory, you can run Python only when the current directory is the directory in which python24.dll resides.

Similarly, python.exe must be in a directory in which Windows looks for executables, normally a directory listed in the Windows environment variable named PATH. How to set PATH and other environment variables depends on your version of Windows, as mentioned in "Environment Variables" on page 22. Python can locate other files, such as the standard library modules, according to various strategies. C:\Py\Python-2.4.3\PC\readme.txt documents the various possibilities. Building Python for Cygwin

Python 2.4 is also available as a part of the free Cygwin Unix-like environment for Windows (see for more information). Cygwin runs on top of Windows. However, Cygwin is quite similar to Linux and other free Unix-like environments in many respects. In particular, Cygwin uses the popular, free gcc C/C++ compiler and associated tools such as make. Building Python from source code on Cygwin is therefore similar to building from source code on Unix-like environments, even though Cygwin runs on Windows.

2.1.2. Unix-Like Platforms

On Unix-like platforms, installing Python from source code is generally simple. In the following sections, for clarity, I assume you have created a new directory named ~/Py and downloaded Python-2.4.3.tgz there. Of course, you can choose to name and place the directory as it best suits you. Uncompressing and unpacking the Python source code

You can uncompress and unpack a .tgz file with programs tar and gunzip. If you have the popular GNU version of tar, you can just type the following at a shell prompt:

$ cd ~/Py
$ tar xzf Python-2.4.3.tgz

Similarly, if you choose to download the substantially smaller .tar.bz2 file instead, again with the GNU version of tar, you could unpack it with the command:

$ tar xjf Python-2.4.3.tar.bz2

With either unpacking procedure, you now have a directory ~/Py/Python-2.4.3, the root of a tree that contains the entire standard Python distribution in source form. Configuring, building, and testing

You will find detailed notes in file ~/Py/Python-2.4.3/README under the heading "Build instructions," and I strongly suggest reading those notes. In the simplest case, however, all you need to get started may be to give the following commands at a shell prompt:

$ cd ~/Py/Python-2.4.3
$ ./configure
    [configure writes much information - snipped here]
$ make
    [make takes quite a while, and emits much information]

If you run make without first running ./configure, make implicitly runs ./configure for you. When make finishes, you should test that the Python you have just built works as expected, as follows:

$ make test
    [takes quite a while, emits much information]

Most likely, make test will confirm that your build is working, but also inform you that some tests have been skipped because optional modules were missing.

Some of the modules are platform-specific (e.g., some work only on machines running SGI's Irix operating system), so you should not worry about them if your machine just doesn't support them. However, other modules are skipped during the build procedure because they depend on other open source packages that may not be installed on your machine. For example, module _tkinterneeded to run the Tkinter GUI package covered in Chapter 17, and also needed to run the IDLE integrated development environment, which comes with Pythoncan be built only if ./configure is able to find an installation of Tcl/Tk 8.0 or later on your machine. See ~/Py/Python-2.4.3/README for more details and specific caveats about many different Unix and Unix-like platforms.

Building from source code lets you tweak your configuration in several useful ways. For example, you can build Python in a special way that will help you track down memory leaks if you develop C-coded Python extensions, covered in "Building and Installing C-Coded Python Extensions" on page 614. Again, ~/Py/Python-2.4.3/README is a good source of information about the configuration options you can use. Installing after the build

By default, ./configure prepares Python for installation in /usr/local/bin and /usr/local/lib. You can change these settings by running ./configure with option --prefix before running make. For example, if you want a private installation of Python in subdirectory py24 of your home directory, run:

$ cd ~/Py/Python-2.4.3
$ ./configure --prefix=~/py24

and continue with make as in the previous section. Once you're done building and testing Python, to perform the actual installation of all files, run:

$ make install

The user running make install must have write permissions on the target directories. Depending on your choice of target directories and the permissions set on those directories, you may therefore need to su to root, bin, or some other special user when you run make install. A common idiom for this purpose is sudo make install: if sudo prompts for a password, enter your current user's password, not root's.

Previous Page
Next Page