From d6514ffe73ac536a1e802a05802b5db261bb4bc4 Mon Sep 17 00:00:00 2001 From: Dave Abrahams Date: Tue, 31 Oct 2000 22:17:51 +0000 Subject: [PATCH] Address STL compatibility claims of CXX Add Paul Dubois quote Add cross-reference link from Prabhu's [sic] Add a write-up of GRAD Remove defunct caveats about multiple-inheritance from extension classes and Python classes, and special attribute names Document Zope reliance on inheritedAttribute Remove anti-Zope slander regarding multiple inheritance [SVN r8085] --- comparisons.html | 102 +++++++++++++++++++++++++++++++++-------------- 1 file changed, 71 insertions(+), 31 deletions(-) diff --git a/comparisons.html b/comparisons.html index d11af0eb..70143db3 100644 --- a/comparisons.html +++ b/comparisons.html @@ -22,16 +22,36 @@ 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. + py_cpp. +

+ As far as I can tell, 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 by the py_cpp object wrappers. CXX claims to interoperate well + with the C++ Standard Library (a.k.a. STL) by providing iterators into + Python Lists and Dictionaries, but the claim is unfortunately + unsupportable. The problem is that in general, access to Python sequence and + mapping elements through iterators requires the use of Proxy objects as + the return value of iterator dereference operations. This usage + conflicts with the basic ForwardIterator requirements in + section 24.1.3 of the standard (dereferencing must produce a + reference). Although you may be able to use these iterators with some + operations in some standard library implementations, it is neither + guaranteed to work nor portable. +

+ Paul F. Dubois, the original + author of CXX, 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. Here is his response to the commentary above: +

+"My intention with CXX was not to do what you are doing. It was to enable a +person to write an extension directly in C++ rather than C. I figured others had +the wrapping business covered. I thought maybe CXX would provide an easier +target language for those making wrappers, but I never explored +that."
-Paul Dubois +

SWIG

@@ -47,21 +67,23 @@ 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 + 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 + realistic), one had to write code by hand. I believe py_cpp doesn't 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. + 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

@@ -92,6 +114,32 @@ to be reserved to the C++ implementation. It is unclear from the documentation whether ILU supports overriding C++ virtual functions in Python. +

GRAD

+

+ GRAD + is another very ambitious project aimed at generating Python wrappers for + interfaces written in "legacy languages", among which C++ is the first one + implemented. Like SWIG, it aims to parse source code and automatically + generate wrappers, though it appears to take a more sophisticated approach + to parsing in general and C++ in particular, so it should do a much better + job with C++. It appears to support function overloading. The + documentation is missing a lot of information I'd like to see, so it is + difficult to give an accurate and fair assessment. I am left with the + following questions: +

+

+ Anyone in the possession of the answers to these questions will earn my + gratitude for a write-up ;-) +

Zope ExtensionClasses

@@ -136,13 +184,12 @@ 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 requires use of the somewhat funky inheritedAttribute (search for + "inheritedAttribute" on this page) + method to access base class methods. In py_cpp, base class methods can + be accessed in the usual way by writing + "BaseClass.method".
  • Zope supplies some creative but esoteric idioms such as @@ -153,13 +200,6 @@ 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 @@ -171,6 +211,6 @@ express or implied warranty, and with no claim as to its suitability for any purpose.

    - Updated: Oct 18, 2000 + Updated: Oct 30, 2000