To install Python 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 the Microsoft product Visual C++.
To download Python source code, visit http://www.python.org 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).
On Windows, installing Python from source code can be a chore unless you are already familiar with Microsoft Visual C++ and 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 the material on installing Python from binaries later in this chapter. It may be a good idea, on Windows, 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 have been 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.2.2.tgz there. Of course, you can choose to name and place the directory as it best suits you.
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 ftp://ftp.objectcentral.com/winutils.zip into C:\Py. If you do not have other ways to unpack a ZIP file, download ftp://ftp.th-soft.com/UNZIP.EXE 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.2.2.tgz C:\Py> tar xvf Python-2.2.2.tar [tar lists the files it is unpacking - omitted here] C:\Py>
Commercial programs WinZip (http://www.winzip.com) and PowerArchiver (http://www.powerarchiver.com) can also uncompress and unpack .tgz archives. Whether via gunzip and tar, a commercial program, or some other program, you now have a directory C:\Py\Python-2.2.2, the root of a tree that contains the entire standard Python distribution in source form.
Open the workspace file C:\Py\Python-2.2.2\PCbuild\pcbuild.dsw with Microsoft Visual C++, for example by starting Windows Explorer, going to directory C:\Py\Python-2.2.2\PCbuild, and double-clicking on file pcbuild.dsw.
Choose Build Set Active Configuration python Win32 Release, then Build Build python.exe. Visual C++ builds projects pythoncore and python, making files python22.dll and python.exe in C:\Py\Python-2.2.2\PCbuild. You can also build other subprojects (for example with Build Batch Build...). However, 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.2.2\PCbuild\readme.txt if you want to build every Python package that is in the distribution.
You can also, optionally, build the debug versions, as well as the release versions, of the Python packages.
With Visual C++, 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, pythoncore produces python22_d.dll and python produces python22_d.exe.
What makes the debugging and release Visual C++ builds incompatible is the choice of runtime library. Executables and DLLs can fully interoperate only by using the same 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 do this only if you are experienced with Microsoft Visual C++ and have special, advanced requirements. Otherwise, resigning yourself to keeping two separate and distinct release and debugging "worlds" is the simplest approach.
python22.dll (or python22_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 python22.dll to a suitable directory, you can run Python only when the current directory is the directory in which python22.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 Chapter 3. Python can locate other files, such as the standard library modules, according to various strategies. C:\Py\Python-2.2.2\PC\readme.txt documents the various possibilities.
Python 2.2 is also available as a part of the free Cygwin Unix-like environment for Windowssee http://cygwin.com/ 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.
On Unix-like platforms, installing Python from source code is not a particularly complicated procedure. In the following sections, for clarity, I assume you have created a new directory named ~/Py and downloaded Python-2.2.2.tgz there. Of course, you can choose to name and place the directory as it best suits you.
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.2.2.tgz
You now have a directory ~/Py/Python-2.2.2, the root of a tree that contains the entire standard Python distribution in source form.
You will find detailed notes in file ~/Py/Python-2.2.2/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.2.2 $ ./configure [configure writes much information - snipped here] $ make [make takes quite a while, and emits much information]
If you run make without running ./configure first, make will implicitly run ./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 only work 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 get skipped during the build procedure because they depend on other open source packages that may not be installed on your machine. For example, module _tkinter, needed to run the Tkinter GUI package covered in Chapter 16, can 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.2.2/README for more details, and also for specific caveats regarding 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 Chapter 24. Again, ~/Py/Python-2.2.2/README is a good source of information about the configuration options you can use.
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 py22 of your home directory, run:
$ cd ~/Py/Python-2.2.2 $ ./configure --prefix=~/py22
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.
Jack Jansen's page on MacPython, http://www.cwi.nl/~jack/macpython.html, is an indispensable resource for any Macintosh Python user. The page includes pointers to specially packaged Python 2.2.2 source code for Macintosh (requiring the CodeWarrior Pro 7 C compiler), prebuilt binaries for both Mac OS X and older Mac OS 9, and a wealth of other Macintosh-specific resources.