Comparisons with Other Systems

CXX

Like py_cpp, CXX attempts to provide a C++-oriented interface to Python. In most cases, like py_cpp, it relieves the user from worrying about reference-counts. As far as I can tell, there is no support for subclassing C++ extension types in Python. An even more-significant difference is that a user's C++ code is still basically "dealing with Python objects", though they are wrapped in C++ classes. This means such jobs as argument parsing and conversion are still left to be done explicitly by the user. This is not entirely a bad thing, as you can do some Pythonic things with CXX (e.g. variable and keyword arguments) that I haven't yet figured out how to enable with py_cpp. As far as I can tell, also CXX enables one to write what is essentially idiomatic Python code in C++, manipulating Python objects through the same fully-generic interfaces we use in Python. That use is also supported (less-well) by the py_cpp object wrappers. Paul F. Dubois, the CXX maintainer, has told me that what I've described is only half of the picture with CXX, but I never understood his explanation well-enough to fill in the other half. I hope that you, dear reader, may be able to help me complete my comparitive analysis of CXX.

SWIG

SWIG is an impressively mature tool for exporting an existing ANSI 'C' interface into various scripting languages. Swig relies on a parser to read your source code and produce additional source code files which can be compiled into a Python (or Perl or Tcl) extension module. It has been successfully used to create many Python extension modules. Like py_cpp, SWIG is trying to allow an existing interface to be wrapped with little or no change to the existing code. The documentation says "SWIG parses a form of ANSI C syntax that has been extended with a number of special directives. As a result, interfaces are usually built by grabbing a header file and tweaking it a little bit." For C++ interfaces, the tweaking has often proven to amount to more than just a little bit. One user writes:

"The problem with swig (when I used it) is that it couldnt handle templates, didnt do func overloading properly etc. For ANSI C libraries this was fine. But for usual C++ code this was a problem. Simple things work. But for anything very complicated (or realistic), one had to write code by hand. I believe py_cpp doesnt have this problem[sic]... IMHO overloaded functions are very important to wrap correctly."
-Prabhu Ramachandran

By contrast, py_cpp doesn't attempt to parse C++ - the problem is simply too complex to do correctly. Technically, one does write code by hand to use py_cpp. The goal, however, has been to make that code nearly as simple as listing the names of the classes and member functions you want to expose in Python.

SIP

SIP is a system similar to SWIG, though seemingly more C++-oriented. The author says that like py_cpp, SIP supports overriding extension class member functions in Python subclasses. It appears to have been designed specifically to directly support some features of PyQt/PyKDE, which is its primary client. Documentation is almost entirely missing at the time of this writing, so a detailed comparison is difficult.

ILU

ILU is a very ambitious project which tries to describe a module's interface (types and functions) in terms of an Interface Specification Language (ISL) so that it can be uniformly interfaced to a wide range of computer languages, including Common Lisp, C++, C, Modula-3, and Python. ILU can parse the ISL to generate a C++ language header file describing the interface, of which the user is expected to provide an implementation. Unlike py_cpp, this means that the system imposes implementation details on your C++ code at the deepest level. It is worth noting that some of the C++ names generated by ILU are supposed to be reserved to the C++ implementation. It is unclear from the documentation whether ILU supports overriding C++ virtual functions in Python.

Zope ExtensionClasses

ExtensionClasses in Zope use the same underlying mechanism as py_cpp to support subclassing of extension types in Python, including multiple-inheritance. Both systems rely on the same "Don Beaudry Hack" that also inspired Don's MESS System.

The major differences are:

• py_cpp lifts the burden on the user to parse and convert function argument types. Zope provides no such facility.
• py_cpp lifts the burden on the user to maintain Python reference-counts.
• py_cpp supports function overloading; Zope does not.
• py_cpp supplies a simple mechanism for exposing read-only and read/write access to data members of the wrapped C++ type as Python attributes.
• Writing a Zope ExtensionClass is significantly more complex than exposing a C++ class to python using py_cpp (mostly a summary of the previous 4 items). A Zope Example illustrates the differences.
• Zope's ExtensionClasses are specifically motivated by "the need for a C-based persistence mechanism". Py_cpp's are motivated by the desire to simply reflect a C++ API into Python with as little modification as possible.
• Thus, Zope's ExtensionClasses support pickling. Currently py_cpp ExtensionClasses do not.
• The following Zope restriction does not apply to py_cpp: "At most one base extension direct or indirect super class may define C data members. If an extension subclass inherits from multiple base extension classes, then all but one must be mix-in classes that provide extension methods but no data."
• Zope's Extension SubClasses admit multiple-inheritance from both Zope ExtensionClasses and Python classes. This capability is currently not available in py_cpp.
• Zope supplies the standard special Python class attributes __doc__, __name__, __bases__, __dict__, and __module__ on its ExtensionClasses; py_cpp does not (coming soon)
• Zope supplies some creative but esoteric idioms such as Acquisition.
• Zope's ComputedAttribute support is designed to be used from Python. The analogous feature of py_cpp can be used from C++ or Python. The feature is arguably easier to use in py_cpp.

Also, the Zope docs say: "The first superclass listed in the class statement defining an extension subclass must be either a base extension class or an extension subclass. This restriction will be removed in Python-1.5." I believe that this promise was made prematurely. I have looked at the Python 1.5.2 source code and I don't believe it is possible to deliver on it.

Previous: A Brief Introduction to writing Python Extension Modules Next: A Simple Example Using py_cpp Up: Top

© Copyright David Abrahams 2000. Permission to copy, use, modify, sell and distribute this document is granted provided this copyright notice appears in all copies. This document is provided "as is" without express or implied warranty, and with no claim as to its suitability for any purpose.

Updated: Oct 18, 2000