Re: Re[13]: Who is py_cpp

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-10-15 21:42:28

----- Original Message -----
From: "Mark Evans" <mark.evans_at_[hidden]>

> CXX is several things at once.  In a roundabout way, your note
> pretty much tells the story.  Still I think that argument packing is
> actually one of CXX's strong points.  Function arguments always come
> as a CXX (C++) Tuple object, which behaves like a Python Tuple.
>  Keywords come in a CXX Dictionary object.  Consequently the C++
>  code doesn't need to call the Python C API parsing stuff.  It's
>  quite nice.

In this regard CXX doesn't give you anything over Python's native 'C' API,
except perhaps a slicker interface to the Tuple and Dictionary. Not to
badmouth this, but it means you expend a fair amount of coding effort
manually making sure the right number and types of arguments were passed to
any function, then extracting or converting them to the appropriate C++
types. With py_cpp none of this is neccessary. You just write your classes
in straightforward C++ and export the member functions with a single line of
C++ code.

> CXX interfaces with STL.  I haven't
> gotten deep into that side of it.  But naturally one is not
> restricted to the use of CXX objects, STL objects, or anything
> else.  However it is quite handy to have (for example) a Pythonic
> String object that can turn itself into an STL
> string.

That particular type conversion is automatic with py_cpp. If you have a
function
   std::string f(const std::string& x) { return x + " pythonically"; }
and you export that with:
   my_module.def(f, "f")
you can simply write in Python:
   >>> f('say something')
   'say something pythonically'

> Finally CXX includes its own ExtensionModule class to handle the
> intricacies of writing a Python extension in C++.

I think I've handled that too... haven't I?

> The one thing that CXX does not do, and what drew us into py_cpp
> and ExtensionClass, is the subclassing of C++ code within Pyhton.
>  You are correct about that.  Off the top of my head, I can't see
>  why there would be a conflict between the two packages (CXX and
>  py_cpp).  If you know of any potential conflicts that will keep
>  either one from working properly with the other, by all means notify me.

I don't think there's any problem, unless CXX doesn't "play nice" (e.g.
defines nasty macros which walk on my symbols), but I don't have any reason
to believe it wouldn't be a good citizen. It should even be possible to add
a py_cpp ExtensionClass<> instance to a CXX ExtensionModule.

> Our company has already settled on CXX but we are fishing around
> for a subclassable-C++ capability.  We might just settle for
> boring old Python wrappers if it comes to that.

Whatever works. I'm just suggesting that unless you have a specific need for
some of the more esoteric features of CXX, that once you've exported your
first class with py_cpp you'll wonder why you bothered with the other system
;->

-Dave