[C++-SIG] Restarting

[Paul F. Dubois]

Comments about some of the points Geoff made. I will for the sake of
discussion point out the capabilities of CXX, but I hope it doesn't sound
defensive. I'm not in love with my implementation and if someone has a
better idea, or a suggestion for revisions, I am very much open to it.

>I will put the latest version of this patch up on the C++ Sig web site
>soon.  I have a little learning to do about how to administer the www
>site for this sig, but as soon as I can, I'll post a patch against the
>1.5.2 distribution which adds autoconf support for C++ enabled python
>configurations.

This would be a big help. I didn't know we had a web site.

>
> > 2.Type safety in the Python API.
>
>There's a lot here, but one of the most basic things I was thinking
>about when I wrote that, was this business of parsing tuples,
>especially arg tuples.  Right now you do this with a format string,
>and you'd better do it right!  What I'd like to see instead, is a
>system that uses C++'s innate awareness of the types of identifiers,
>to directly construct those format strings on your behalf.  There are
>probably similar issues involved with extracting elements from the
>various Python containers.

CXX does not use format strings. Instead, you simply extract the elements of
the tuple using index notation. The strong typing occurs because an attempt
to construct a CXX class such as List with a python object that isn't a
list, will throw an exception. And of course, there are queries available as
to type. The CXX test routines illustrate this. I'm not opposed to the
PyArg_ParseTuple wrapping, I just didn't find it particularly helpful.
>
> > 3.Introducing C++ classes for the various major Python abstractions,
> > such as dictionaries, lists, tuples, modules, etc.

That is there, although some things need work, and some of the more obscure
Python objects aren't there, functions being the most notable. (Callable,
yes.)
>
..><snip>  I figure we need, is to look
>at the list of all Python C API entry points.  They all look sort of
>like: Py<Pkg>_<Operation>.  To me, this would seem to translate
>naturally to:
>
>namespace Py {
>    class <Pkg> {
>        PyObject *<Operation>( ... );

I think most of the time we want to be focused on the objects, not the
operation. CXX contains a lot of the C API.

> A little additional work to bring [] subscripting
>operators to Dicts and so forth, seems prudent as well.

This is in CXX.

> > 4.Providing semantics for these classes which are natural both to the
> > Python programmer, as well as the C++ programmer. For example, the
> > PyDict class should have an operator[], and should also support STL
> > style iterators. Many issues of this form.

CXX has both.

>
>Here I was trying to say that the wrapper classes implemented above,
>should be good STL citizens.  However, that was only loosely defined
>at the time that I wrote it.  Now I would point to the recently
>published "Generic Programming and the STL" by Matt Austern, which
>contains comprehensive documentation of the services exported by the
>STL components.  We should try to make our classes that wrap the
>Python C API, support the services of similarly named STL classes as
>much as possible.

I tried, but the documentation needed was pretty bad. My classes probably
(certainly!) are not going to turn out to be completely correct STL
container classes, but they are close.

I will get this book. Thanks for the reference.

>So there may be
>some issues about just how "normal" we can make the Python C++ wrapper
>classes look, in comparison to their STL counterparts, but we should
>do what we can.

CXX sequences are templated on the type of object the iterator returns.

>
>In particular, I think it ought to be possible to to at least
>implement enough services to support a wide sampling of the STL
>algorithms, operating over the elements of the Python containers.  For
>example, maybe we need to write a functor library so you can write
>something like:
>
>Py::Dict a;
>// Fill a with elements, either from C++ or from Python script
>// language.
>sort( a.begin(), a.end(), PyLexicographicalLess<Py::String>() );

This works in CXX, although I didn't particularly experiment with the third
argument any, since Python objects have a built-in less. But it should work.
>
>
> > 5.Method invocation. How to make the invocation of C++ member
> > functions as natural and/or painless as possible.

That's the part I got stuck on. I did succeed in a mechanism for creating
C++ classes that are decendents of PyObject and that have the necessary
tables and methods for setting them, and which have simple mechanisms for
setting the behaviors but one is left with a clumsy gap between the methods
of the class and the glue function needed for the behavior or method as a
python object.

> > 6.Error handling. How to irradicate NULL checking in favor of C++
> > style exceptions.


CXX requires no null checking, it is all done with exceptions. But as you
and I have discussed, it would be possible perhaps to obviate the need for
the try block in user code. It isn't that onerous, but the fact that the try
/ catch could be hoisted is tempting.

>the C++ community.  I've been working with developer snapshots of egcs
>for several months now.  10/5/98 was the snapshot that marked the
>viability of egcs in my book.  I'm pretty sure that current egcs
>snapshots will successfully handle code at the level of what Paul and
>I have put up on this list before

I tried about two months ago and it was close but no cigar...it lacked a
standard library, for one thing, and support for virtual methods in
templated classes. VC++ on Windows does work. But I share your optimism.