CXX is designed to make it easier to extend Python with C++

Using CXX_Objects

The distribution is in the LLNL distribution under directory CXX. The subdirectory cxx contains the header file CXX_Objects.h and the implementation file cxxobjects.cxx. If your compiler does not support namespaces you will need to edit CXX_config.h to so indicate.

All declarations in CXX_Objects.h are in a namespace "Py", and so you may wish to use it in the form:

#include "CXX_Objects.h"
using namespace Py;

The second part of CXX is a facility to make it easier to create extension modules and extension objects. Also provided is a file CXX_Extensions.h and its support file cxxextensions.c. While the latter is a C file, it is written so as to compile properly with either a C or a C++ compiler. It is not necessary to use this part of CXX in order to use CXX_Objects.h.

A directory "example" is provided in the distribution.  The example demonstrates both parts of CXX..

First we consider the CXX_Objects.h facilities.

The essential idea is that we avoid, as much as possible, programming with pointers to Python objects, that is, variables of type PyObject*. Instead, we use instances of a family of C++ classes that represent the usual Python objects. This family is easily extendible to include new kinds of Python objects.

For example, consider the case in which we wish to write a method, taking a single integer argument, that will create a Python dict and insert into it that Python int plus one under the key value. In C we might do that as follows:

static PyObject*
mymodule_addvalue (PyObject* self, PyObject* args) {
	PyObject *d;
	PyObject* f;
	int k;
	PyArgs_ParseTuple(args, "i", &k);
	d = PyDict_New();
	if (!d) {
		return NULL;
	}
	f = PyInt_NEW(k+1);
	if(!f) {
		Py_DECREF(d); /* have to get rid of d first */
		return NULL;
	}
	if(PyDict_SetItemString(d, "value", f) == -1) {
		Py_DECREF(f);
		Py_DECREF(d);
		return NULL;
	}
	return d;
}

static PyObject* 
mymodule_addvalue (PyObject* self, PyObject* pargs) { 
	try { 
		Tuple args(pargs); 
		args.verify_length(1); 
		Dict d; 
		Int k = args[0]; 
		d["value"] = k + 1;
		return new_reference_to(d); 
	} 
	catch (const PyException&) { 
		return NULL;
	}
}

The basic concept of CXX_Objects is to create a wrapper around PyObject*s so that the reference counting can be done automatically, thus eliminating the most frequent source of errors. In addition, we can then add methods and operators so that Python manipulations in C++ can look more like Python.

Each Object contains a PyObject* to which it owns a reference. (If you don’t know what this phrase means, it is explained in the Python extension manual. You don’t actually need to understand it very well if you are going to use CXX_Objects. When an Object is destroyed, it releases its ownership on the pointer. Since C++ calls the destructors on objects that are about to go out of scope, we are guaranteed that we will keep the reference counts right even if we unexpectedly leave a routine with an exception.

Int s(3)

virtual bool accepts(PyObject* p)

Indeed, since most of the Python C API is similarly embodied in Object and its descendents, you probably will not use FromAPI all that often.

The Basic Types

Corresponding to each of the basic Python types is a class that inherits from Object. Here are the interfaces for those types. Each of them inherits from Object and therefore has all of the inherited methods listed for Object. Where a virtual function is overridden in a class, the name is underlined.

Class Type

Class Type corresponds to Python type objects. There is no default constructor.

Table 2: class Type

Class Int

Class Int, derived publically from Object, corresponds to Python ints. Note that the latter correspond to C long ints. Class Int has an implicit user-defined conversion to long int. All constructors, on the other hand, are explicit. The default constructor creates a Python int zero.

Table 3: class Int

Class Long

Class Long, derived publically from Object, corresponds to Python type long. In Python, a long is an integer type of unlimited size, and is usually used for applications such as cryptography, not as a normal integer. Implicit conversions to both double and long are provided, although the latter may of course fail if the number is actually too big. All constructors are explicit. The default constructor produces a Python long zero.

Table 4: Class Long

Class Float

Class Float corresponds to Python floats, which in turn correspond to C double. The default constructor produces the Python float 0.0.

Table 5: Class Float

Sequences

CXX implements a quite sophisticated wrapper class for Python sequences. While every effort has been made to disguise the sophistication, it may pop up in the form of obscure compiler error messages, so in this documentation we will first detail normal usage and then discuss what is under the hood.

The basic idea is that we would like the subscript operator [] to work properly, and to be able to use STL-style iterators and STL algorithms across the elements of the sequence.

Sequences are implemented in terms of a templated base class, SeqBase<T>. The parameter T is the answer to the question, sequence of what? For Lists, for example, T is Object, because the most specific thing we know about an element of a List is simply that it is an Object. (Class List is defined below; it is a descendent of Object that holds a pointer to a Python list). For strings, T is Char, which is a wrapper in turn of Python strings whose length is one. 

For convenience, the word Sequence is typedef'd to SeqBase<Object>.

General sequences

Suppose you are writing an extension module method that expects the first argument to be any kind of Python sequence, and you wish to return the length of that sequence. You might write:

static PyObject*
my_module_seqlen (PyObject *self, PyObject* args) {
    try {
        Tuple t(args); // set up a Tuple pointing to the arguments.
        if(t.length() != 1) throw PyException("Incorrect number of arguments to seqlen.");
        Sequence s = t[0]; // get argument and be sure it is a sequence
        return new_reference_to(Int(s.length()));
    }
    catch(const PyException&) {
        return Py_Null;
    }
}

As we will explain later, the try/catch structure converts any errors, such as the first argument not being a sequence, into a Python exception.

Subscripting

When a sequence is subscripted, the value returned is a special kind of object which serves as a proxy object. The general idea of proxy objects is discussed in Scott Meyers' book, "More Effective C++". Proxy objects are necessary because when one subscripts a sequence it is not clear whether the value is to be used or the location assigned to. Our proxy object is even more complicated than normal because a sequence reference such as s[i] is not a direct reference to the i'th object of s.

In normal use, you are not supposed to notice this magic going on behind your back. You write:

Object t;
Sequence s;
s[2] = t + s[1]

and here is what happens: s[1] returns a proxy object. Since there is no addition operator in Object that takes a proxy as an argument, the compiler decides to invoke an automatic conversion of the proxy to an Object, which returns the desired component of s. The addition takes place, and then there is an assignment operator in the proxy class created by the s[2], and that assignment operator stuffs the result into the 2 component of s.

It is possible to fool this mechanism and end up with a compiler failing to admit that a s[i] is an Object. If that happens, you can work around it by writing Object(s[i]), which makes the desired implicit conversion, explicit.

Iterators

Each sequence class provides the following interface. The class seqref<T> is the proxy class. We omit the details of the iterator, const_iterator, and seqref<T> here. See CXX_Objects.h if necessary. The purpose of most of this interface is to satisfy requirements of the STL.

The SeqBase<T> Interface

SeqBase<T> inherits from Object.

Any heir of class Object that has a sequence behavior should inherit from class SeqBase<T>, where T is specified as the type of object that represents the individual elements of the sequence. The requirements on T are that it has a constructor that takes a PyObject* as an argument, that it has a default constructor, a copy constructor, and an assignment operator. In short, any properly defined heir of Object will work.

Classes Char and String

Python strings are unusual in that they are immutable sequences of characters. However, there is no character type per se; rather, when subscripted strings return a string of length one. To simulate this, we define two classes Char and String. The Char class represents a Python string object of length one. The String class represents a Python string, and its elements make up a sequence of Char's.

The user interface for Char is limited. Unlike String, for example, it is not a sequence.

The Char interface

Char inherits from Object.

The String Interface

String inherits from SeqBase<Char>.

Class Tuple

Class Tuple represents Python tuples. A Tuple is a Sequence. There are two kinds of constructors: one takes a PyObject* as usual, the other takes an integer number as an argument and returns a Tuple of that length, each component initialized to Py_None. The default constructor produces an empty Tuple.

Tuples are not immutable, but attempts to assign to their components will fail if the reference count is not 1. That is, it is safe to set the elements of a Tuple you have just made, but not thereafter.

Example: create a Tuple containing (1, 2, 4)

Tuple t(3)
t[0] = Int(1)
t[1] = Int(2)
t[2] = Int(4)

Example: create a Tuple from a list:

Dict d
...
Tuple t(d.keys())

The Tuple Interface

Tuple inherits from Sequence.. Special run-time checks prevent modification if the reference count is greater than one.

Class List

Class List represents a Python list, and the methods available faithfully reproduce the Python API for lists. A List is a Sequence.

The List Interface

List inherits from Sequence.

Mappings

A class MapBase<T> is used as the base class for Python objects with a mapping behavior. The key behavior of this class is the ability to set and use items by subscripting with strings. A proxy class mapref<T> is defined to produce the correct behavior for both use and assignment.

For convenience, Mapping is typedefed as MapBase<Object>.

The MapBase<T> interface

MapBase<T> inherits from Object. T should be chosen to reflect the kind of element returned by the mapping.

Class Dict

Class Dict represents Python dictionarys.  A Dict is a Mapping. Assignment to subscripts can be used to set the components.

Dict d
d["Paul Dubois"] = "(925)-422-5426"

Interface for Class Dict

Dict inherits from MapBase<Object>.

Other classes and facilities.

Class Callable provides an interface to those Python objects that support a call method. Class Module holds a pointer to a module. (If you want to create an extension module, however, see the extension facility). There is a large set of numeric operators.

Interface to class Callable

Interface to class Module

Numeric interface

Unary operators for plus and minus, and binary operators +, -, *, /, and % are defined for pairs of objects and for objects with  scalar integers or doubles (in either order).  Functions abs(ob) and coerce(o1, o2) are also defined.

The signature for coerce is:

inline std::pair<Object,Object> coerce(const Object& a, const Object& b)

Unlike the C API function, this simply returns the pair after coercion.

Stream I/O

Any object can be printed using stream I/O, using std::ostream& operator<< (std::ostream& os, const Object& ob).  The object's str() representation is converted to a standard string which is passed to std::ostream& operator<< (std::ostream& os, const std::string&).

Exceptions

The Python exception facility and the C++ exception facility can be merged via the use of try/catch blocks in the bodies of extension objects and module functions.

Class Exception and its children

A set of classes is provided. Each is derived from class Exception, and represents a particular sort of Python exception, such as IndexError, RuntimeError, ValueError. Each of them (other than Exception) has a constructor which takes an explanatory string as an argument, and is used in a throw statement such as:

throw IndexError("Index too large in MyObject access.");

If in using a routine from the Python API, you discover that it has returned a NULL indicating an error, then Python has already set the error message. In that case you merely throw Exception.

List of Exceptions

Using Exceptions in extension methods

The exception facility allows you to integrate the C++ and Python exception mechanisms. To do this, you must use the style described below when writing module methods.

Catching Exceptions from the Python API or CXX.

When writing an extension module method, you can use the following boilerplate. Any exceptions caused by the Python API or CXX itself will be converted into a Python exception. Note that Exception is the most general of the exceptions listed above, and therefore this one catch clause will serve to catch all of them. You may wish to catch other exceptions, not in the Exception family, in the same way. If so, you need to make sure you set the error in Python before returning.

static PyObject *
some_module_method(PyObject* self, PyObject* args)
{
    Tuple a(args); // we know args is a Tuple
    try {
        ...calculate something from a...
        return ...something, usually of the form new_reference_to(some Object);
    }
    catch(const Exception&) {
        //Exception caught, passing it on to Python
        return Null ();
    }
}

How to clear an Exception

If you anticipate that an Exception may be thrown and wish to recover from it, change the catch phrase to set a reference to an Exception, and use the method clear() from class Exception to clear it.:

catch(Exception& e) {
        e.clear();
...now decide what to do about it...
}

Extension Facilities

CXX_Extensions.h provides facilities for:

• Creating a Python extension module
• Creating new Python extension types

These facilities use CXX_Objects.h and its support file cxxmodule.cxx, but not vice-versa. Therefore, the decision about whether or not to use this part of CXX is up to you.

Creating an Python extension module

The usual method of creating a Python extension module is to declare and initialize its method table in C. This requires knowledge of the correct form for the table and the order in which entries are to be made into it, and requires casts to get everything to compile without warning. CXX's header file PyExtensions.h offers a simpler method. Here is a sample usage, in which a module named "example" is created. Note that two details are necessary:

• The initialization function must be declared to have external C linkage.
• The ExtensionModule object must have a storage class that survives the call to the initialization function. This is most easily accomplished by using a static local inside the initialization function.

In this example, two module methods ex_sum and ex_test have already been defined, with the usual signature:
PyObject* method_name (PyObject*, PyObject*).

extern "C" void initexample();

void initexample()
{
    static ExtensionModule example("example");
    example.add("sum", ex_sum, "sum(arglist) = sum of arguments");
    example.add("test", ex_test, "test(arglist) runs a test suite");
    Dict d = example.initialize();
   
   // Now we can add to the module dictionary if we wish...
   
    Float pi(3.14159);
    d["pi"] = pi;
}

Interface to class ExtensionModule

Creating a Python extension type

One of the great things about Python is the way you can create your own object types and have Python welcome them as first-class citizens. Unfortunately, part of the way you have to do this is not great. Key to the process is the creation of a Python "type object". All instances of this type must share a reference to this one unique type object.  The type object itself has a multitude of "slots" into which the addresses of functions can be added in order to give the object the desired behavior.

CXX mitigates this difficulty with class PythonExtension. PythonExtension is a templated class, and the way you use it is very odd indeed: you make your new object type inherit from it, giving itself as the template parameter:

class MyObject: public PythonExtension<MyObject> {...}

This causes several good things to happen:

• MyObject is a child of PyObject, so that a MyObject* is-a PyObject*.
• A static method check(PyObject*) is created in class MyObject. This function returns a boolean, testing whether or not the argument is in fact a pointer to an instance of MyObject.
• An (empty) table of object methods is created (MyObject::methods). The user can add object methods to this table.
• A PythonType object is created (MyObject::behaviors). The required Python type object is hidden inside this wrapper object. The wrapper object has methods to set the desired behaviors.
• A method is created to handle the deletion of an instance if and when its reference count goes to zero. This method ensures the calling of the class destructor ~MyObject(), if any, and releases the memory (see below).
• Both automatic and heap-based instances of MyObject can be created.

Sample usage of PythonExtension

This example is given in full in the Demo directory. See files r.h and r.cxx. The "r" object has three public data members and a number of methods. The implementations are omitted here.

class r: public PythonExtension<r> {
public:
    long start;
    long stop;
    long step;
   
    r(long start_, long stop_, long step_ = 1L) ;
    ~r();
    long length() const ;
    long item(int i) const ;
    r* slice(int i, int j) const;
    r* extend(int k) const;
    std::string asString() const ;
    Object value(const Tuple&) const;
    void assign(const Tuple&, const Object& rhs) ;
};

Some work by Geoffrey Furnish of LANL may obviate the next step, but for now one must create "glue" routines to connect the methods of the class to Python. Again, see the demo for the full text of the functions; we show a few here for flavor.

#include "r.h"
// Connect r objects to Python

static PyObject *
r_repr(PyObject* arg)
{
    r* robj = static_cast<r*>( arg);
    return new_reference_to(String(robj->asString()));
}

static int
r_length(PyObject* arg)
{
    r* robj = static_cast<r*>( arg);
    return robj->length();
}

... other behavior methods

// "regular" methods...
static PyObject *
r_amethod(PyObject* self, PyObject* args)
{
    Tuple t(args);
...
   return new_reference_to(result);
}

Finally, we must write (and call from some module's initialization routine) this initialization function. In this initialization function we set the desired behaviors and methods of the object.

    Note that we do not and must not set our own dealloc behavior. Class PythonExtension has already done so.

void init_rtype () {
    r::behaviors().name("r");
    r::behaviors().doc("r objects: start, stop, step");
    r::behaviors().repr(r_repr);
    r::behaviors().getattr(r_getattr);
    r::behaviors().sequence_length(r_length);
    r::behaviors().sequence_item(r_item);
    r::behaviors().sequence_slice(r_slice);
    r::behaviors().sequence_concat(r_concat);
    r::methods().add("amethod", r_amethod);
    r::methods().add("assign", r_assign);
    r::methods().add("value", r_value);
}

To complement this, we add the method r_new to a module so that objects of type "r" can be created from Python. Note how it simply uses the creation function from class r in a standard way:

PyObject*
r_new (PyObject* self, PyObject* args) {
    try {
        Tuple rargs(args);
rargs.verify_length(2, 3); // make sure there are 2 or 3 arguments
        Int start(rargs[0]);
        Int stop(rargs[1]);
        Int step(1);
        if (rargs.length() == 3) {
            step = rargs[2];
        }
        if (long(start) > long(stop) + 1 || long(step) == 0) {
            throw RuntimeError("Bad arguments to r(start,stop [,step]).");
        }
        return new r(start, stop, step);
    }
    catch(const Exception&) {
        return Null ();
    }
}

Notes on memory management and extension objects

Normal Python objects exist only on the heap. That is unfortunate, as object creation and destruction can be relatively expensive. Class PythonExtension allows creation of both local and heap-based objects.

If an extension object is created using operator new, as in:

r* my_r_ref = new r(1, 20, 3)

then the entity my_r_ref can be thought of as "owning" the reference created in the new object. Thus, the object will never have a reference count of zero. If the creator wishes to delete this object, they should either make sure the reference count is 1 and then do delete my_r_ref, or decrement the reference with Py_DECREF(my_r_ref).

Should my_r_ref give up ownership by being used in an Object constructor, all will still be well. When the Object goes out of scope its destructor will be called, and that will decrement the reference count, which in turn will trigger the special dealloc routine that calls the destructor and deletes the pointer.

If the object is created with automatic scope, as in:

r my_r(1, 20, 3)

then my_r can be thought of as owning the reference, and when my_r goes out of scope the object will be destroyed. Of course, care must be taken not to have kept any permanent reference to this object. Fortunately, in the case of an exception, the C++ exception facility will call the destructor of my_r. Naturally, care must be taken not to end up with a dangling reference, but such objects can be created and destroyed more efficiently than heap-based PyObjects.

Putting it all together

The Demo directory of the distribution contains an extensive example of how to use many of the facilities in CXX. It also serves as a test routine. This test is not completely exhaustive but does excercise much of the facility.

Acknowledgment

Thank you to Geoffrey Furnish for patiently teaching me the finer points of C++ and its template facility, and his critique of CXX in particular.