exposing boost uuid with SWIG

Question

I have my existing working code that depends on boost::uuids::uuid . Now I an trying to generate a python module out of it. SWIG is successfully generating all important classes and functions. But I am facing problem with the functions that takes or returns boost uuid.

I want to convert between boost uuid and python uuid. Is there any uuid.i that I can use ? I see there is an uuid python module.I understand I can import that module from an uuid.i with PyImport_ImportModule("uuid") .

But how to instantiate and use the python's uuid class inside typemap ?

Answer 1

This is fairly straight forward to do any you're on the right lines with the PyImport_ImportModule call. What you need to do is figure out how you're going to marshal the UUIDs between the two types and then write one typemap for each direction. I ended up going via string representations since that's the simplest portable way to do it in my view. That's using uuid_io.hpp 's IO operators in both directions.

When we wrap it like this Python code never see's the boost type at all and vice-versa.

I've assumed you're targeting Python 3.4 here, but everything I've done should be simple adjust to target older Python with too.

First I put together a C++ header file to demonstrate the wrapping I implemented:

#include <boost/uuid/uuid.hpp>
#include <boost/uuid/random_generator.hpp>
#include <boost/uuid/uuid_io.hpp>
#include <iostream>

inline boost::uuids::uuid testout() {
    static boost::uuids::random_generator gen;
    return gen();
}

inline void testin(const boost::uuids::uuid& in) {
    std::cout << in << "\n";
}

Nothing clever there, just one function each for each direction of passing the objects.

Next I wrote some Python to exercise the interface I wanted to produce:

import test
import uuid

a=test.testout()
print(type(a))
print(a)

b=uuid.uuid4()
print(type(b))
print(b)

test.testin(a)
test.testin(b)

And finally a SWIG interface that would generate this module, once I've written the actual UUID wrapping.

%module test

%{
#include "test.hh"
%}

%include "boost_uuid.i"

%include "test.hh"

With all this in place we can now write an implementation boost_uuid.i that works for our scenario:

%{
#include <boost/uuid/uuid_io.hpp>
#include <boost/uuid/uuid.hpp>
#include <sstream>

namespace {
    PyObject *py_uuid = nullptr;
}   
%}

%init %{
    py_uuid = PyImport_ImportModule("uuid"); // Handle error
%}

%typemap(in) const boost::uuids::uuid& (boost::uuids::uuid tmp) {
    PyObject *str = PyObject_Str($input);
    assert(str); // TODO: check properly
    const char *uuid_str = PyUnicode_AsUTF8(str); // Note: Python 3.x, adjust as needed
    assert(uuid_str); // TODO: check me
    std::istringstream in(uuid_str);
    Py_DECREF(str);
    in >> tmp; // TODO: Check return!
    $1 = &tmp;
}

%typemap(out) boost::uuids::uuid {
    // Check this actually works!
    static PyObject *uuid_ctor = PyObject_GetAttrString(py_uuid, "UUID");
    std::ostringstream out;
    out << $1;
    PyObject *str = PyUnicode_DecodeUTF8(out.str().c_str(), out.str().size(), NULL);
    // Theoretically this string conversion could have just failed
    $result = PyObject_CallFunctionObjArgs(uuid_ctor, str, NULL);
    Py_DECREF(str);
}

I did contemplate using boost::python to simplify some of this code a little since it's boost we're wrapping. In the end I didn't bother with that though.

You could also use boost's lexical_cast to avoid the stringstream that I've used. That's largely a matter of taste.

None of this is going to be super high performance code, but then when you're passing across language boundaries it also isn't likely to be the bottleneck in your system anyway. You could use the byte-by-byte access that both boost and Python's UUID module give as well and make it just be a direct copy operation, but I avoided that because of the requirement to consider endianness which increased the complexity.

Note:

1. No proper error handling
2. No typemap for pass by value on boost UUID input types.
3. No typemap for pass by non-const reference for input.

All of those should be fairly easy to add as required using this as a starting point.

This compiles and runs as expected:

swig3.0 -c++ -python -py3 -Wall test.i
g++ -g -std=c++1y -shared test_wrap.cxx -o _test.so -I/usr/include/python3.4 -Wall -Wextra -lpython3.4m 
python3.4 run.py
<class 'uuid.UUID'>
b37c9285-f055-4f08-b4e9-4a238be3b09d
<class 'uuid.UUID'>
cf1071e6-2e7f-45af-8920-a68290ee61d4
b37c9285-f055-4f08-b4e9-4a238be3b09d
cf1071e6-2e7f-45af-8920-a68290ee61d4