In this book, the term integration has largely meant mixing Python with components written in C or C++ (or other C-compatible languages) in extending and embedding modes. But from a broader perspective, integration also includes any other technology that lets us mix Python components into larger systems. This last section briefly looks at a handful of integration technologies beyond the C API tools weve seen in this part of the book.
We met JPython in Chapter 15but it is worth another mention in the context of integration at large. As we saw earlier, JPython supports two kinds of integration:
In other words, JPython allows Python to be both extended and embedded in Java, much like the C integration strategies weve seen in this part of the book. With the addition of the JPython system, Python may be integrated with any C-compatible program by using C API tools, as well as any Java-compatible program by using JPython.
Although JPython provides a remarkably seamless integration model, Python code runs slower in the JPython implementation, and its reliance on Java class libraries and execution environments introduces Java dependencies that may be a concern in some development scenarios. See Chapter 15 for more JPython details; for the full story, read the documentation available online at http://www.jython.org (also available in the JPython package at http://examples.oreilly.com/python2).
We briefly discussed Pythons support for the COM object model on Windows when we explored Active Scripting in Chapter 15, but its really a general integration tool that is useful apart from the Internet too.
Recall that COM defines a standard and language-neutral object model with which components written in a variety of programming languages may integrate and communicate. Pythons win32all Windows extension package tools allow Python programs to implement both server and client in the COM interface model.
As such, it provides a powerful way to integrate Python programs with programs written in other COM-aware languages such as Visual Basic, Delphi, Visual C++, PowerBuilder, and even other Python programs. Python scripts can also use COM calls to script popular Microsoft applications such as Word and Excel, since these systems register COM object interfaces of their own. Moreover, the newcomer Python implementation (tentatively called Python.NET) for Microsofts C#/.NET technology mentioned in Chapter 15 provides another way to mix Python with other Windows components.
On the downside, COM implies a level of dispatch indirection and is a Windows-only solution at this writing. Because of that, it is not as fast or as portable as some of the lower-level integration schemes weve studied in this part of the book (linked-in, in-process, and direct calls between Python and C-compatible language components). For nontrivial use, COM is also considered to be a large system, and further details about it are well beyond the scope of this book.
For more information on COM support and other Windows extensions, refer to Chapter 15 in this book, and to OReillys Python Programming on Win32. That book also describes how to use Windows compilers to do Python/C integration in much more detail than is possible here; for instance, it shows how to use Visual C++ tools to compile and link Python C/C++ integration layer code. The basic C code behind low-level extending and embedding on Windows is the same as shown in this book, but compiling and linking details vary.
There is also much support, some of it open source, for using Python in the context of a CORBA-based application. CORBA stands for the Common Object Request Broker; its a language-neutral way to distribute systems among communicating components, which speak through an object model architecture. As such, it represents another way to integrate Python components into a larger system.
Pythons CORBA support includes the public domain systems ILU (from Xerox) and fnorb (see http://www.python.org). At this writing, the OMG (Object Management Group, responsible for directing CORBA growth) is also playing host to an effort to elect Python as the standard scripting language for CORBA-based systems. Whether that ultimately transpires or not, Python is an ideal language for programming distributed objects, and is being used in such a role by many companies around the world.
Like COM, CORBA is a large system -- too large for us to even scratch the surface in this text. For more details, search Pythons web site for CORBA-related materials.
Given so many integration options, choosing between them can be puzzling. When should you choose something like COM over writing C extension modules, for instance? As usual, it depends on why you e interested in mixing external components into your Python programs in the first place.
Basically, frameworks such as JPython, COM, and CORBA allow Python scripts to leverage existing libraries of software components, and do a great job of addressing goals like code reuse and integration. However, they say almost nothing about optimization: integrated components are not necessarily faster than the Python equivalents.
On the other hand, Python extension modules and types coded in a compiled language like C serve two roles: they too can be used to integrate existing components, but also tend to be a better approach when it comes to boosting system performance.
Lets consider the big picture here. Frameworks such as COM and CORBA can perhaps be understood as alternatives to the Python/C integration techniques we met in this part of the book. For example, packaging Python logic as a COM server makes it available for something akin to embedding -- many languages (including C) can access it using the COM client-side interfaces we met in Chapter 15. And as we saw earlier, JPython allows Java to embed and run Python code and objects through a Java class interface.
Furthermore, frameworks allow Python scripts to use existing component libraries: standard Java class libraries in JPython, COM server libraries on Windows, and so on. In such a role, the external libraries exposed by such frameworks are more or less analogous to Python extension modules. For instance, Python scripts that use COM client interfaces to access an external object are acting much like importers of C extension modules (albeit through the COM indirection layer).
Pythons C API is designed to serve in many of the same roles. As weve seen, C extension modules can serve as code reuse and integration tools too -- its straightforward to plug existing C and C++ libraries into Python with SWIG. In most cases, we simply generate and import the glue code created with SWIG to make almost any existing compiled library available for use in Python scripts. Moreover, Pythons embedding API allows other languages to run Python code, much like client-side interfaces in COM.
 In fact, its so easy to plug in libraries with SWIG that extensions are usually best coded first as simple C/C++ libraries, and later wrapped for use in Python with SWIG. Adding a COM layer to an existing C library may or may not be as straightforward, but will clearly be less portable -- COM is currently a Windows-only technology.
One of the primary reasons for writing C extension modules in the first place, though, is optimization: key parts of Python applications may be implemented or recoded as C or C++ extension modules to speed up the system at large (as in the last chapters stack examples). Moving such components to compiled extension modules not only improves system performance, but is completely seamless -- module interfaces in Python look the same no matter what programming language implements the module.
By contrast, JPython, COM, and CORBA do not deal directly with optimization goals at all; they serve only to integrate. For instance, JPython allows Python scripts to automatically access Java libraries, but generally mandates that non-Python extensions be coded in Java,a language that is itself usually interpreted and no speed demon. COM and CORBA focus on the interfaces between components and leave the component implementation language ambiguous by design. Exporting a Python class as a COM server, for instance, can make its tools widely reusable on Windows, but has little to do with performance improvement.
Because of their different focus, frameworks are not quite replacements for the more direct Python/C extension modules and types weve studied in these last two chapters, and are less direct (and hence likely slower) than Pythons C embedding API. Its possible to mix-and-match approaches, but the combinations are rarely any better than their parts. For example, although C libraries can be added to Java with its native call interface, its neither a secure nor straightforward undertaking. And while C libraries can also be wrapped as COM servers to make them visible to Python scripts on Windows, the end result will probably be slower and no less complex than a more directly linked-in Python extension module.
As you can see, there are a lot of options in the integration domain. Perhaps the best parting advice I can give you is simply that different tools are meant for different tasks. C extension modules and types are ideal at optimizing systems and integrating libraries, but frameworks offer other ways to integrate components -- JPython for mixing in Java tools, COM for reusing and publishing objects on Windows, and so on. As ever, your mileage may vary.
Part I: System Interfaces
Parallel System Tools
Larger System Examples I
Larger System Examples II
Part II: GUI Programming
Graphical User Interfaces
A Tkinter Tour, Part 1
A Tkinter Tour, Part 2
Larger GUI Examples
Part III: Internet Scripting
Larger Web Site Examples I
Larger Web Site Examples II
Advanced Internet Topics
Part IV: Assorted Topics
Databases and Persistence
Text and Language
Part V: Integration
VI: The End
Conclusion Python and the Development Cycle