[PYTHON C++-SIG] LLNL Python/C++ integration: current status

[Barry A. Warsaw]

First an aside: I have not tracked C++ developments very closely since
coming here to CNRI about 2 1/2 years ago, so I'm only dimly aware of
details of the new features like RTTI, exceptions, and namespaces.  I
used to have one of the earliest editions of the ARM.  Would you
recommend getting a new edition, or is there a better reference manual
I can get to bone up on these features?

All in all, not doing any real C++ work these days, I still think your
approach looks really good.  I like the natural feel this would give
to a C++er.  Please excuse the few pretty trivial comments,
suggestions, and questions.

>>>>> "GF" == Geoffrey Furnish <furnish at laura.llnl.gov> writes:

 > 3) Introducing C++ classes for the various major Python abstractions,
 >    such as dictionaries, lists, tuples, modules, etc.

    GF> Python really look this way to the C++ programmer.  Planned
    GF> classes at this time include:

    GF> PyDict
    GF> PyList
    GF> PyTuple

    GF> and possible also PyArgs,
    
I'd only suggest adding the word `Class' on the end here, (or maybe
`Wrapper') e.g. PyDictClass.  Although `PyDict' may never conflict
with other names in the C API, there are symbols like `PyDict_Type'.
It seems like it could cause confusion, for example, what if you
passed a PyDict object to PyDict_Type?  That would seem to me a
natural thing to want to do given the naming.

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

    GF> Finally, our C++ wrapper over the Python C API allows the
    GF> abolition of all NULL checking.

This is very cool.

[code deleted]

On the C++ coding styles.  I used to code C++ very similar to the
style you seem to use.  This is at odds with the standard Python C
coding style.  If this stuff ever makes it into the core (and I hope
something like it does), it will make life easier if the stuff to be
integrated looks like the core C style, where appropriate of course.
[If you're an Emacs user, the latest cc-mode has a "python" style that
gets you close].  Maybe Guido can post some pointers to his style
guide.  Maybe he'd just tell me its too trivial to matter right now.
Maybe I've just been mucking about in the Python core too much. :-)

    GF> By this point, people should be getting the pretty clear image
    GF> that these extensions exercise the C++ language at a level
    GF> very close to the draft standard.

I respect this decision, and actually hope you can get away with it,
especially since it makes the C++ API that much cleaner.

    GF> human error).  This is another area where our C++ interface
    GF> will de-C-ize the Python API.  Instead of calling ParseTuple
    GF> with a format string and gobs of pointers, you'll just call it
    GF> directly with the variables you want filled in.  The template
    GF> system, using the C++ "traits" technique, will construct the
    GF> format string for you, and populate the argumenfs.

Could you give me a quick primer on what the "traits" technique is?
This is definitely something new to me.

-Barry

_______________
C++-SIG - SIG for Development of a C++ Binding to Python

send messages to: c++-sig at python.org
administrivia to: c++-sig-request at python.org
_______________