This chapter introduces using Python on Windows. Rather than describe how to use Python on Windows, we discuss the architecture and briefly cover some of the extension modules available.
When you install the Python binaries for Windows, you install a fully functional version of Python that runs under Windows. This version of Python is similar to what you would find on any installation of Python, regardless of the platform, and we begin by briefly discussing how to take full advantage of the standard Python on Windows.
Although this standard version of Python is fully functional, you don't obtain much Windows-specific functionality. To fill the gap, there is a standard set of extensions for Python known collectively as the Python for Windows extensions. These extensions provide access to many Windows-specific features, such as a GUI and IDE environment, Microsoft's COM, the raw Win32 API, Windows NT-specific features, and so forth. We assume you have already installed the Python for Windows extensions, so these extensions are covered in detail. As discussed in Chapter 1, What Is Python?, you can find the latest official version of these extensions at http://www.python.org/windows (look for the Windows 95/NT-specific extensions entry).
To complete the picture, we also discuss some other extension modules available for Python on Windows. Many of these are not Windows-specific, but do support Windows, so they are worthy of discussion. Extensions falling into this category include OpenGL, mxTools, Zope, PIL, and others.
Python is an Open Source tool, and on many platforms, the standard way to install Python is to download the Python sources and run an automated procedure for compiling Python on the machine, resulting in Python binaries that are installed and ready to use. The key advantage of this process is that it can be customized for a particular installation; if you have a specific requirement, it can normally be accommodated.
Under Microsoft Windows, however, this strategy doesn't work. Most people don't have C compilers, and probably would not be happy with the arrangements even if they did. Therefore, Python provides an installation package that contains a version of Python built with useful default options. The installation allows you to choose which components are installed from the following:
� The Python core implemented in a Windows DLL named Python1x.dll (e.g., Python15.dll for the Python 1.5 family). This DLL is installed into your PC's Windows system directory.
� The standard Python executable, Python.exe. This provides the default interactive prompt and allows you to run Python programs. Additionally, Pythonw.exe is also installed, which allows you to write GUI applications using Python. Only advanced users should employ Pythonw.exe, because Python errors aren't printed; this means that Pythonw.exe usually appears to do nothing, and this is intentional. You should avoid using Pythonw.exe until you are proficient with Python itself.
� A few useful Python extension modules providing an interface to such things as .zip compatible compression, the Tkinter GUI library, and so forth. Python extension modules are implemented as Windows DLLs, but are typically provided as .pyd files. For example, the interface to the zlib compression tool is a DLL named zlib.pyd.
� The Python library as Python source files (.py). The Python library contains many useful cross-platform modules for working with Python. These include the basic Python library (such as the string and os modules), as well as advanced modules, such as web servers or modules for inspecting and decoding various audio format files.
� The Python test suite. This is a set of Python source files that test the Python installation. In general, you don't need to run these tests: they are designed primarily to test ports of Python to new architectures, or by the creators of Python to test major changes to Python itself. If you really feel a need to run this, you can start the Python interpreter and execute the command:
>>> import test.autotest
Python responds with:
test_grammar
test_opcodes
test_operations
test_builtin
test_exceptions
test_types
test_al
test test_al skipped -- an optional feature could not be imported
�
A hundred or so lines will print over the next few minutes; it takes some time to complete. Note the last message printed; you will see many of these warnings, and they can be safely ignored.
� The Python documentation in HTML format, accessible from the Windows Start Menu.
� Headers (.h files) and libraries (.lib files) for the C components needed to build your own extension modules. This is covered in Chapter 22, Extending and Embedding with Visual C++ and Delphi.
� The portable GUI environment Tkinter and a Python IDE known as IDLE. Tkinter is discussed in more detail in Chapter 20, GUI Development, while IDLE is discussed in Chapter 4, Integrated Development Environments for Python.
� Various Python scripts and utility programs. Browse the \tools subdirectory of your Python installation.
You should browse the supplied Python documentation. You will find a reference guide for most of the standard library, as well as the language tutorial and reference. Additionally, you should check for later documentation at http://www. python.org/doc/; it's quite common for new documentation to be written between major Python releases, and the latest documentation is always available for online browsing or download in both HTML and printable (PostScript/PDF) formats.
When Python is installed, a number of configuration options are stored in the Windows registry. The Windows registry provides a central location where programs can store their preferences and settings and provides more features than traditional techniques of saving configuration information. The Windows registry also has some limitations, and many people would dearly like to see it suffer a slow and painful death! Whatever your views, good Windows applications, and therefore Python, store their information in the Windows registry.
In general, it isn't necessary for you to understand or edit the registry; Python and any extensions you install normally manages this for you. Indeed, if you are unfamiliar with the Windows registry, you should avoid it completely: it's all too easy to do serious damage to your PC's configuration. However, if you are experienced with the Windows registry or are curious to see how everything works, read on.
The most important configuration option stored in the registry is the PythonPath, the list of directories where Python looks to find modules, which can be viewed at runtime via sys.path. Under Unix, the common way of storing this option is by setting a PYTHONPATH environment variable. Under Windows, this information is stored in the registry rather than in the environment.*
Python also stores other configuration data in the registry, including the location where Python was installed, a list of Python help files, and so forth. For full details on Python's use of the registry, please see the Python documentation.
Let's take a quick look at the Python registry information using the standard Windows Registry Editor. Start the Registry Editor by executing the program regedit.exe (or possibly regedt32.exe on Windows 95, depending on the configuration). You should see a window that looks similar to the Windows Explorer: a list of folders on the left, and data on the right.
Locate the folder named HKEY_LOCAL_MACHINE, and expand it. Locate the subfolder named Software, and expand it, then continue down through the Python, PythonCore, 1.5, and PythonPath subfolders. Your screen should look something like Figure 3-1, which shows the default PythonPath (i.e., the path used by the Python core) has been installed in E:\Program Files\Python, and the three existing path subkeys: PythonWin, win32, and win32com. These entries have been added by the Python for Windows extensions and contain the additional PythonPath entries required by the respective packages.
If you need to add your own PythonPath entry, you can create a subkey under the PythonPath key and add your new path entries to the key. The names of the keys are for documentation purposes only; they are the name of the package that requires the path entry. Only the key values are actually used by Python itself.
 The registry is a system-level tool that allows you freedom to do irreparable damage to your operating system, requiring complete reinstallation. Be careful with any changes you make to the registry and make no changes unless you are certain of their impact. |
||||
| * It should be noted that Python on Windows can also use the PYTHONPATH environment variable, but by default the value is stored in the registry. |
 |
||||
| Figure 3-1. The Windows Registry Editor |
||||
If you open the Windows Explorer after installing Python, you might notice that all .py and .pyc files have their own cute Python icon! If you right-click on a .py file, notice the default menu entry is Run; you can select this entry from the menu or double-click on the .py file to run the program using the standard Python.exe. It's possible that other Python extensions will install new items in this menu; for example, PythonWin (discussed later in this chapter) adds an Edit item, allowing you to open the Python source file for editing.
In addition, you can drag these .py files to your favorite text editor (including PythonWin) for editing. This can be any editor of your choice, or even the standard Windows notepad tool.*
Running Python programs from the Windows Explorer has one major problem: a new window is created for the Python program, and when it terminates, the window closes immediately. This means that any messages displayed by the program (either informational or error messages) usually vanish just as you are trying to read them. For this reason, most Windows users don't execute their Python programs in this manner; they do so either from the Windows command prompt or
| * Many standard Python library files are supplied with Unix-style line terminators. notepad is still one of the few Windows editors unable to cope with files of this format. For this and other reasons, you shouldn't use notepad to edit Python source. |
from a Python integrated development environment (IDE), such as PythonWin or IDLE.
Both the Windows 95/98 and NT/2000 families come with a command prompt allowing users to run programs from a command-line interface. The Windows command prompt has a long and not-so-glorious history; it has grown from the first versions of MS-DOS and still uses the same basic syntax.
For these discussions, let's assume you have a file named C:\Scripts\hello.py, and this file consists of the single line:
print "Hello from Python"
A first attempt to run this program may surprise you:
C:\Scripts>python.exe hello.py
The name specified is not recognized as an
internal or external command, operable program or batch file.
C:\Scripts>
Although Python.exe has been installed, it hasn't modified the system environment variable PATH: Windows doesn't know how to find Python.exe. Windows NT does, however, know how to run .py files directly. Thus, if you ask the command prompt to execute hello.py, it will:
C:\Scripts>hello.py
Hello from Python
C:\Scripts>
Take this one step further and avoid the use of the .py extension, making a Python program appear like a .exe, .com, or .bat file. Windows NT supports this using the PATHEXT environment variable. You can view the current settings of this variable by entering the command:
C:\Scripts>echo %PATHEXT%
.exe; .bat; .cmd
C:\Scripts>
This is a list of the default extensions Windows searches for when a command is executed. You can add Python files to this list (and check the change was successful) by executing:
C:\Scripts>set PATHEXT=%PATHEXT%; .py
C:\Scripts>echo %PATHEXT%
.exe; .bat; .cmd; .py
C:\Scripts>
Now execute your Python programs by specifying the base name of the file:
C:\Scripts>hello
Hello from Python
C:\Scripts>
For more information, please see the Windows NT documentation.
Unfortunately, none of this applies to Windows 95 or 98, only to Windows NT and 2000. Users of Windows 95 or 98 often take one of the following actions:
� Add the Python directory to the system environment variable PATH by modifying their autoexec.bat file.
� Copy Python.exe to the Windows system directory. The biggest problems with this are that it's one more file in an already overused directory, and when Python is upgraded, this file may cause some conflicts.
The facilities we described that are available under Windows NT usually make these changes unnecessary.
Finally, both operating systems support using the start command to start Python in a separate window. For example, you could use the command start python. exe to start an interactive Python.exe in a new window or the command start hello.py to run your script in a new window. However, just as with Windows Explorer, this window closes as the program exits, meaning you don't get a chance to read the message printed by your script.
All versions of Windows have some capability for command-line editing: that is, recalling previous commands that have been entered, so they can be reexecuted without retyping them.
Windows NT supports command-line editing by default, but Windows 95 and 98 require you to execute a program named doskey before this functionality is available. Windows 95 and 98 users often configure their environment so that doskey is automatically executed whenever a command prompt is started.
To operate the command-line editing tools, use the arrow keys on the keyboard. The up and down arrows scroll between the commands you executed recently, while the left and right arrow keys allow you to edit the current command. In addition, Windows NT also provides command-line editing for Python.exe; once you start Python, you can recall previous commands in the same way you can at the command prompt. Unfortunately, Windows 95 or 98 doesn't offer this feature.
The doskey program can also provide command macros. A command macro is a shortcut you assign to a program, so when the shortcut is executed the command prompt, the program is executed.
You can-use this to your advantage when working with Python. For example, Windows 95 users who can't take advantage of the Windows NT command prompt can use the following command to assign the shortcut p to execute Python:
C:\Scripts> doskey p="C:\Program Files\Python\Python.exe" $*
The $* at the end of the command indicates that any command-line parameters should be passed to the program, in this case, Python. Thus, you could execute:
C:\Scripts>p hello.py
Hello from Python
C:\Scripts>
Users of Windows NT and Windows 95 may also like to use these shortcuts to execute their favorite editor. For example, if you execute the following commands:
C:\Scripts>doskey n=start notepad.exe $*
C:\Scripts>doskey pw=start pythonwin.exe $*
you could use:
C:\Scripts>n hello.py
to edit the file using notepad, or:
C:\Scripts>pw hello.py
to edit the file using PythonWin.
To take advantage of these doskey macros, you can place them all in a single batch file that can be configured to be run whenever a command prompt is opened. There are many techniques, but a simple one is to place all the commands in a batch file, then modify the shortcut you use to execute the command prompt to include the parameter /k your_batchfile.bat. This forces the command prompt to execute your batch file, but remains open, allowing you to continue entering commands.
Although fairly minor, there are a couple of other features that can help you work with Python.
The first is Copy and Paste. Both Windows 95 and NT support an option that allows you to copy text from the command prompt using the mouse. Windows NT also allows you to paste information into your command prompt with a simple right-click of the mouse. This can be handy when you need to paste a string or sample code into your Python prompt. You can enable this by selecting the Quick Edit option from the command prompt's properties.
Another nice feature for all versions is that you can drag a file from Windows Explorer and drop it into a command prompt, pasting the full filename to the prompt. This can be a handy way to execute Python programs from Windows Explorer without losing the output when the program completes: simply drop the filename onto an existing command prompt and press Enter.
As we have stressed a number of times, Python is cross-platform. Although the sheer market penetration of Windows makes it one of Python's most popular platforms, it's still only one of the many operating systems Python has to work with.
Accordingly, there are some features available on other platforms that don't exist on Windows. To make matters worse, there are a number of features that do work on both platforms, but not in exactly the same way.
Most people who use Python only on Windows never need to worry about these features; they have probably never heard of these functions anyway, and they won't find further comment on them in this book. But for people moving to Windows from the Unix and Linux worlds, seemingly trivial things can cause much aggravation. Although far from exhaustive, some of the more common gotchas are detailed here.
Since the early days of computing (well before Unix), lines in text files were terminated with carriage-return and line-feed characters. This is directly attributable to the early teletype devices that required a command to move the printhead (or carriage) back to the left, and another to eject a new line. The creators of Unix decided the convention was pointless and terminated all lines in text files by the line-feed character, which by then had become known as the newline character. Then the C language came up with a new technique for opening files, such that regardless of the local line-ending conventions, your program would always see a consistent single newline character at the end of each line. A differentiation was made between binary- and text-mode files, which was specified when opening the file.
Unfortunately, over time many Unix programmers became somewhat lazy. As Unix uses a single newline character to terminate lines anyway, there was no difference on that operating system between text- and binary-mode files; the program always worked identically on Unix, regardless of the mode used to open the file. Over time, it became common practice for programmers to omit the binary- or text-mode specifiers completely. To add to the confusion, we also have the Apple Macintosh, which uses a single carriage return.
Windows traces its roots right back to the old teletype days. Every version of Windows, including the most recent, has had to retain some level of compatibility with early versions of MS-DOS, and MS-DOS itself strove to retain some compatibility with CP/M. As a direct result of this history, the common default-line terminator on Windows is a carriage-return character followed by a newline character. This is the file format editors such as notepad use. Most modern editors (including most you are likely to use with Python) support either line convention.
The end result of all this discussion comes down to two points:
� If you open a file and wish to see a single newline character terminating each line (regardless of what really terminates the lines), the file should be opened in text mode. You should open in text mode on all operating systems, including Unix where it will have no effect; you never know when some poor soul will try to run your code on a different operating system!
� If you open a file and need to see the raw, binary data, you should specify binary mode.
If you open a file in text mode, but it contains binary data, the data often appears corrupt due to the newline and carriage-return mapping. If you open a file in binary mode but you process it as if it contained text data, each line may have additional (or missing) carriage returns at the end of each line.
To open a file in binary mode, append a b to the mode in the open() call. The default is text mode, but on Windows, you can also specify this by appending a t. Thus, to open a file for reading in text mode, use this:
file = open(filename, "r")
Or to open a file for writing in binary mode , use this:
file = open(filename, "wb")
Unix provides a function called fork() to spawn subprocesses. fork() is often used in situations where Windows programmers would consider using threads. Until recently, some of the more popular Unix systems didn't have support for threads, and those that did frequently had their own proprietary API, making it dif-
ficult to write portable, threaded code for Unix. fork() has a number of subtleties and features that make it particularly useful in this context, and thus fork() is widespread in the Unix world.
Windows doesn't support fork() and, unfortunately, doesn't support anything that comes close. If you have a Unix program that uses fork(), then porting it to run under Windows is likely to be significant work and requires fairly intimate understanding of the program.
In many cases, the best solution is to rebuild this part of the application for Windows. On a typical Unix machine, creating new processes (as fork() does) is a relatively cheap operation. On Windows, however, the overhead of creating a new process is significant, so solutions using this architecture on Windows won't often scale or perform as you would hope. Rewriting this portion of the application to use multiple threads instead of multiple processes is often the best solution for Windows.
Python exposes the fork() function in the os module (i.e., os.fork()) on platforms that support it. As Windows isn't one of these supporting platforms, using os.fork() yields an AttributeError exception.
Another common Unixism that causes problems on Windows is the use of the select() function. Under Unix, the select() function determines when more input is available from a file. When your program is reading a file on a disk, you won't have much use for this function. However, it's common for programs to be reading from files that are not on disk: for example, reading the output of another process (i.e., a pipe) or reading data from a network connection. By being notified when a particular file has more data available to read, using select() allows a program to read from multiple files concurrently.
Windows does provide the select() function, but it can be used only with sockets (see Chapter 19, Communications). Attempting to use select() with a regular Python file object will fail.
The most common technique on Windows for simple asynchronous input/output is to use threads; and indeed threads are the only portable technique to perform this style of I/O in Python. A simple thread-based solution doesn't scale well once the number of threads becomes large, so Windows provides other native techniques for performing asynchronous I/O. Although these techniques are beyond the scope of this book, they are all fully supported by Python on Windows.
This issue is similar to the one outlined previously for os.fork(): a feature for working with subprocesses that doesn't work as you may hope on Windows.
Quite often, Unix programs use a function called os.popen() to create a child process and establish a pipe between your process and the new child. Depending on the direction of the pipe, you can read the output from the process or supply input to the process. The most common use of os.popen() is to execute a program and capture its output. When you read from the pipe, you are actually reading the output of the child process.
Although provided under Windows, the os.popen() function is practically useless. Due to various bugs in Windows, os.popen() works only on Windows NT from a console (i.e., DOS prompt) program. Windows 95, 98, and Windows NT GUI programs all fail when attempting to use os.popen().
Bill Tutt has come to the rescue with his various popen() replacement functions for Windows. These functions are exposed in the win32pipe module and documented in the standard Win32 Extensions Help file.
To supplement the standard Python distribution, there is a set of extensions specific to Microsoft Win32 platforms (currently Windows NT/2000, Windows 95/98, and Windows CE).
These extensions actually consist of three discrete Python extensions: access to the native Win32 API, interfaces to COM, and the PythonWin GUI extensions. These are currently released as a single unit, in an installation package named win32all. Each specific release is given a build number that is incorporated into the installation name; at time of printing, the current build number is 128, so the installation package is named win32all-128.exe. By the time you read this, the build number is likely to have advanced, so install the version recommended by the web page when you connect. For obvious reasons, this package is also known as the ''win32all package.''
The Python for Windows extensions can be found at http://www.python.org/windows and also at http://starship.python.net/crew/mhammond.
The most fundamental interface to Windows features is provided by the Win32 extensions. In most cases, these modules provide access similar to the Win32 API
that C or C++ programmers would have, such as access to Windows handles and other low-level concepts.
Table 3-1 displays the Win32 extension modules.
| ||||||||||||||||||||||||||||
| ||||||||||||
When the extensions are installed, a Reference Manual (a Windows Help file) is installed detailing each of the methods and their parameters.
You will notice that some modules have a "helper" companion; for example, the win32evtlog module has a helper named win32evtlogutil. In all cases, the core module exposes the native Windows API, and the "helper" provides more convenient access to that API.
When you install the Python for Windows extensions, an environment known as PythonWin is also installed. One of the most noticeable changes that occurs when you install the extensions is that a shortcut to PythonWin is installed into the Python group on the Windows Start menu.
PythonWin is a GUI environment and IDE for Python. When you start PythonWin, you are presented with an interactive window (a window where you can enter and execute arbitrary Python commands, similar to Python.exe). You can also edit and execute .py files within the environment, using a graphical debugger if necessary. Finally, you can also use the PythonWin framework to create your own GUI-based programs.
Technically, PythonWin consists of two discrete parts:
� A large Python extension that exposes the Microsoft Foundation Classes (MFC) to Python. MFC is a C++ library provided by Microsoft to create Windows programs. Similar to MFC itself, this extension can be considered a toolkit; it contains all the elements you need to build GUI applications, but it isn't an application itself.
� A set of Python modules that use these MFC facilities to create the IDE environment you see when you start PythonWin. These modules can almost be considered sample code for the MFC extensions.
As you run PythonWin, it's worth nothing that almost all the functionality you are using is written in Python. Everything from handling the menu commands to updating the line and character positions on the status bar is implemented in the supplied .py Python source files.
PythonWin is discussed in more detail in Chapter 4.
The Python for Windows extensions also include excellent support for the Microsoft Component Object Model (COM). COM is a technology that allows you to use "objects" from your favorite language, even if the object isn't implemented in your language.
Microsoft has invested heavily in COM, and it should be familiar to any Visual Basic programmer. Many applications for Windows (including Microsoft Office) can be controlled using COM, making it particularly suitable for scripting-related tasks; for example, a Python program to open an Excel spreadsheet and populate the sheet is quite simple, as we shall see later in the book.
COM and PythonCOM are discussed in Chapter 5, Introduction to COM, and in more detail in Chapter 12, Advanced Python and COM.
The Python Imaging Library (PIL) is a set of modules that can perform all sorts of image manipulation and processing in Python. PIL is designed to be cross-platform, so it can be used on almost any platform with Python support. But it does support some Windows-specific extensions, allowing PIL to display images using the Windows API.
PIL is suitable for many image-related tasks. You can use it to create thumbnails automatically from a collection of images, to convert between graphical formats, or even as the basis of a graphical image-manipulation tool.
PIL comes with extensive documentation and can be found on the Internet at http://www.pythonware.com.
OpenGL is a high-performance, portable 2D and 3D rendering library. OpenGL was created in 1992 by Silicon Graphics and quickly became the industry standard for 2D and 3D graphics. It's currently maintained by an independent industry consortium, the OpenGL Architecture Review Board. More information on OpenGL can be found at http://www.opengl.org.
Most versions of Microsoft Windows support the OpenGL standard. Windows NT and 98 both come with OpenGL support installed by default, while Windows 95 has an add-on available to obtain OpenGL support.
David Ascher, a well-known Python luminary and O'Reilly author, currently maintains a set of Python extensions that allow interface to the OpenGL libraries known as PyOpenGL. OpenGL and PyOpenGL are both cross-platform libraries, and both are also supported on Windows.
OpenGL is a complex API, and a good book on OpenGL is highly recommended before you attempt to use the library. The PyOpenGL pages recommend the following books:
� Woo, Neider & Davis, OpenGL Programming Guide, Second Edition: The Official Guide to Learning OpenGL, Version 1.1, Addison Wesley Developers Press. ISBN: 0-201-46138-2.
� Kemp & Frasier, OpenGL Reference Guide, Second Edition: The Official Reference Document to OpenGL, Version 1.1, Addison Wesley Developers Press. ISBN: 0-201-46140-4.
PyOpenGL itself comes with a number of demos that use the Tkinter graphics library, and PythonWin comes with a single sample that demonstrates how to use OpenGL in the PythonWin environment.
Information on PyOpenGL can be found at http://starship.python.net/crew/da/PyOpenGL.
There are a number of Internet publishing tools available for Python. Python itself comes with its own HTTP server (web server), which is discussed in some detail in Chapter 15, Using the Basic Internet Protocols.
A number of packages have extended Python's capability in this area; these include the Medusa Suite and Zope.
Medusa is a platform for building high-performance, long-running servers using Python, written by Sam Rushing of Nightmare Software. Medusa uses an asynchronous model for supporting high-performance, single-threaded servers, particularly suitable for HTTP or FTP servers. Although Medusa comes with HTTP and FTP servers, the library is suitable for almost any high-performance/high-load socketbased communication; in fact, the core Medusa engine was recently adopted as part of the standard Python library and can be found on any standard Python 1.5.2 or later distribution.
Medusa is currently used by a number of mission-critical systems around the world. It's free for personal use, although it requires a license for commercial use.
Information on Medusa can be found at http://www.nightmare.com/medusa.
Zope is an Open Source application server and portal toolkit supplied and supported by Digital Creations. While a quick look at Zope may give you the impression it's yet another web server, it's actually far more.
Most web servers earn their living by serving static HTML text, or possibly executing code using the CGI interface. Instead of serving HTML pages, Zope publishes "objects" stored in the integrated object database, a relational database, or other content systems such as LDAP servers. Zope maps these requests to Python objects, which are retrieved from the object database and queried. Whenever you display a page using Zope, you are actually calling some Python object. You can easily create new types of publishable objects and use any Python facilities including Windows-specific Python extensions. At the time of this writing a Zope extension to facilitate the use of COM objects is in development.
This provides a natural way of developing content for the Web. You design your web page as a combination of HTML templates and a set of objects. The templates can reference your objects to obtain the final HTML sent to the user.
While Zope's HTML templates may resemble IIS ASP files, they operate quite differently. Rather than being bound to web pages like ASP files, Zope templates are associated with Python objects. A Zope template builds a web representation of an object by calling the object's methods and/or calling other objects and their templates. In this way web pages are built out of assemblages of objects and their templates.
Unlike ASP, Zope can operate with almost any web server and can run on almost any platform that supports Python. Zope comes with its own web server, but it can also operate hand in hand with other web servers such as IIS. When you use Zope with IIS, Zope runs as an NT service, and IIS forwards web requests to Zope for processing.
As Zope is released as Open Source, it's free, including for commercial use. In addition to customizing Zope for your own purposes, you can participate in
Zope's development by following changes in Concurrent Versioning System (CVS), proposing features, submitting patches, and contributing extensions.
Further information can be found at http://www.zope.org; the site also provides a handy demo.
Not necessarily written for Windows platforms, but nevertheless worth a look, are the extensions written for Python by Marc-André Lemburg. Most extensions come with a Python-style license and can be freely used for your own projects (although some do require a license for commercial use: see the license for details). Many of them even include precompiled binaries for direct use on Windows; installation is then a matter of unzipping the package archive.
You can download the most recent versions from the Starship server, where many other Pythoneers also keep their gems. The documentation, license information, and download instructions are all just a few clicks away from http://starship.python.net/crew/lemburg/.
mxDateTime provides three new object types, DateTime, DateTimeDelta, and RelativeDateTime, which let you store and handle date/time values in a more natural way than by using Unix ticks (seconds since 1.1.70 0:00 UTC, the encoding used by the standard Python time module). We'll see this used in Chapter 13, Databases.
You can add, subtract, and even multiply instances, or use the standard Python pickle module to copy them and convert the results to strings, COM dates, ticks, and some other more esoteric values. In addition, there are several convenient constructors, formatters, and parsers to greatly simplify dealing with dates and times in real-world applications.
Besides providing an easy-to-use Python interface, the package also exports a comfortable C API interface for other extensions to build on. This is especially interesting for database applications that often have to deal with date/time values; the mxODBC package is one example of an extension using this interface.
mxTextTools includes several useful functions and types that implement high-performance text-manipulation and searching algorithms.
For experts, mxTextTools also includes a flexible and extensible state machine, the Tagging Engine, that allows scanning and processing text based on low-level bytecode "programs" written using Python tuples. It gives you access to the speed of C without having to compile and link steps every time you change the parsing description.
Applications include parsing structured text, finding and extracting text (either exact or using translation tables), and recombining strings to form new text.
mxODBC is an extension package that provides a Python Database API-compliant interface to ODBC 2.0-capable database drivers and managers.
Apart from implementing the standard Database API interface, it also gives access to a rich set of catalog methods that allow you to scan the database for tables, procedures, and so forth. Furthermore, it uses the mxDateTime package for date/time value interfacing eliminating most of the problems these types normally introduce (other I/O formats are available too).
The latest versions of the package allow you to interface to more than one database from one process. It includes a variety of preconfigured setups for many commonly used databases such as MySQL, Oracle, Informix, Solid, and many more. A precompiled version of the extension for the Windows ODBC manager is also included.
Chapter 13 covers mxODBC in considerable detail.
This is one of the smaller offerings: mxStack implements a new object type called Stack. It works much as you would expect from such a type, having .push() and .pop() methods and focusing on obtaining maximum speed at low memory costs.
The mxTools package is collection of handy functions and objects extending Python's functionality in many useful ways. You'll find many goodies you've often missed in this package, such as dict() for constructing dictionaries from item lists or a replacement for range (len(object)) called indices(). There are more than 25 new functions provided by this package; too many to detail here, and listing only a few runs the risk of skipping the one you might find most useful. The online documentation provides an excellent reference.
mxCrypto is an extension package that provides object-oriented-style access to the cipher algorithms and hash functions included in SSLeay, a sophisticated cryptographic library written by Eric Young, now maintained by the OpenSSL (http://www.openssl.org) team.
SSLeay/OpenSSL isn't subject to the U.S. government's International Traffic in Arms Regulations (ITAR) export restrictions on cryptographic software, so it's available worldwide.
This small package gives you complete control of how an object may be accessed and by whom. It's suitable to implement bastion-like features without the need to run in restricted execution environments.
The package features secure data encapsulation (the hidden objects are not accessible from Python since they are stored in internal C structures), customizable attribute lookup methods, and a cleanup protocol that helps to break circular references prior to object deletion.
Python is popular in scientific circles. One of the first major packages to come from this environment is Numeric Python. Numeric Python supports efficient multidimensional arrays and can perform complex number-crunching chores normally reserved for packages such as MATLAB or IDL. Also included in Numeric Python are tools for working with linear algebra, Fast Fourier Transforms, and so forth.
Apart from Numeric Python, other scientific tools include support for managing huge sets of data, extensions for plotting and other data analysis, and others.
All these tools are released under a license similar to that of Python and can be found at the Python web site, http://www.python.org/topics/scicomp/.
Python provides excellent support for the Extensible Markup Language (XML), one of the recent hot topics in the computer science world. XML is a format for structured data interchange and is being widely adopted by many influential corporations, including Microsoft. Python has a number of validating and nonvalidating parsers available and a number of tools for working with the Document Object Model (DOM). There is extensive sample code and an active SIG mailing list.
Releases of the XML toolkit usually come with a prebuilt Python binary for Windows. The package is distributed under a license similar to that of Python, so the latest source code is always available.
Information on Python support for XML and links to general XML resources can all be found at the Python web site, http://www.python.org/topics/xml/.
In this chapter, we have attempted to discuss Python on Windows without showing any Python code! We focused on using Python in the Windows environment and how Python integrates with the standard Windows tools.
We discussed some extensions you may find useful on Windows. By talking about only a few, we run the risk of giving the impression that these are the only Python modules available for Windows, and this would be unfair. There are many other useful Python extensions, either designed for Windows or that work perfectly on Windows.
To find the particular module you are after, you should use the facilities provided at http://www.python.org/search/ to search the main Python web site, other Python-related web sites, and the main Python newsgroup.