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. . This would be a big help. I didn't know we had a web site. > > >. 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. > . 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. > >() ); 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.  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.