views:

654

answers:

5

I am attempting to create python bindings for some C++ code using swig. I seem have run into a problem trying to create python properties from some accessor functions I have for methods like the following:

class Player {
public:
  void entity(Entity* entity);
  Entity* entity() const;
};

I tried creating a property using the python property function but it seems that the wrapper classes swig generates are not compatible with it at least for setters.

How do you create properties using swig?

A: 

Hello,

I don't know what I'm talking about, at all, but you can take a look at Boost.Python - it seems pretty easy...

http://www.boost.org/doc/libs/1_39_0/libs/python/doc/index.html

Kevin
Actually I already have bindings in boost python form but found they were a pain to maintain. If swig can't do properties however I will probably keep using boost python.
fuzzy-waffle
+2  A: 

Ooh, this is tricky (and fun). SWIG doesn't recognize this as an opportunity to generate @property: I imagine it'd be all too easy to slip up and recognize lots of false positives if it weren't done really carefully. However, since SWIG won't do it in generating C++, it's still entirely possible to do this in Python using a small metaclass.

So, below, let's say we have a Math class that lets us set and get an integer variable named "pi". Then we can use this code:

example.h

#ifndef EXAMPLE_H
#define EXAMPLE_H

class Math {
 public:
    int pi() const {
        return this->_pi;
    }

    void pi(int pi) {
        this->_pi = pi;
    }

 private:
    int _pi;
};

#endif

example.i

%module example

%{
    #define SWIG_FILE_WITH_INIT
    #include "example.h"
%}

[essentially example.h repeated again]

example.cpp

#include "example.h"

util.py

class PropertyVoodoo(type):
    """A metaclass. Initializes when the *class* is initialized, not
    the object. Therefore, we are free to muck around the class
    methods and, specifically, descriptors."""

    def __init__(cls, *a):
        # OK, so the list of C++ properties using the style described
        # in the OP is stored in a __properties__ magic variable on
        # the class.
        for prop in cls.__properties__:

            # Get accessor.
            def fget(self):
                # Get the SWIG class using super. We have to use super
                # because the only information we're working off of is
                # the class object itself (cls). This is not the most
                # robust way of doing things but works when the SWIG
                # class is the only superclass.
                s = super(cls, self)

                # Now get the C++ method and call its operator().
                return getattr(s, prop)()

            # Set accessor.
            def fset(self, value):
                # Same as above.
                s = super(cls, self)

                # Call its overloaded operator(int value) to set it.
                return getattr(s, prop)(value)

            # Properties in Python are descriptors, which are in turn
            # static variables on the class. So, here we create the
            # static variable and set it to the property.
            setattr(cls, prop, property(fget=fget, fset=fset))

        # type() needs the additional arguments we didn't use to do
        # inheritance. (Parent classes are passed in as arguments as
        # part of the metaclass protocol.) Usually a = [<some swig
        # class>] right now.
        super(PropertyVoodoo, cls).__init__(*a)

        # One more piece of work: SWIG selfishly overrides
        # __setattr__. Normal Python classes use object.__setattr__,
        # so that's what we use here. It's not really important whose
        # __setattr__ we use as long as we skip the SWIG class in the
        # inheritance chain because SWIG's __setattr__ will skip the
        # property we just created.
        def __setattr__(self, name, value):
            # Only do this for the properties listed.
            if name in cls.__properties__:
                object.__setattr__(self, name, value)
            else:
                # Same as above.
                s = super(cls, self)

                s.__setattr__(name, value)

        # Note that __setattr__ is supposed to be an instance method,
        # hence the self. Simply assigning it to the class attribute
        # will ensure it's an instance method; that is, it will *not*
        # turn into a static/classmethod magically.
        cls.__setattr__ = __setattr__

somefile.py

import example
from util import PropertyVoodoo

class Math(example.Math):
    __properties__ = ['pi']
    __metaclass__  = PropertyVoodoo

m = Math()
print m.pi
m.pi = 1024
print m.pi
m.pi = 10000
print m.pi

So the end result is just that you have to create a wrapper class for every SWIG Python class and then type two lines: one to mark which methods should be converted in properties and one to bring in the metaclass.

Hao Lian
This looks like it should do the trick! It is a shame SWIG doesn't have a more direct mechanism for making properties.
fuzzy-waffle
Is there any declaration syntax that it will recognize as a property? getPropName/setPropName maybe?
Toji
It doesn't look like SWIG tries to generate those, although I only spent about an hour or so with SWIG documentation in writing the code for this answer and it's entirely possible there's a way I haven't come across.
Hao Lian
+1  A: 

Hao Lian's answer is excellent but the specific PropertyVoodoo code seems to fail if there is more than one entry in the properties list. I've inserted that code directly into %pythoncode blocks in my SWIG input file and seem to be close to getting past this very annoying problem.

Joel Welling
A: 

I had the same problem and the advice to use %pythoncode worked for me. Here is what I did:

class Foo {
  // ...
  std::string get_name();
  bool set_name(const std::string & name);
};

In the wrapper:

%include "foo.h"
%pythoncode %{
def RaiseExceptionOnFailure(mutator):
  def mutator(self, v):
    if not mutator(self, v):
     raise ValueError("cannot set property")
  return wrapper
Foo.name = property(Foo.get_name, RaiseExceptionOnFailure(Foo.set_name))
%}
Ross Kinder
A: 

The problem with Hao's ProperyVoodoo metaclass is that when there are multiple properties in the properties list, all the properties behave the same as the last one in the list. For example, if I had a list or property names ["x", "y", "z"], then the properties generated for all three would use the same accessors as "z".

After a little experimentation I believe I've determined that this problem is caused by the way Python handles closures (ie. names within nested functions that refer to variables in the containing scope). To solve the problem, you need to get local copies of the property name variable into the fget and fset methods. It's easy enough to sneak them in using default arguments:

# (NOTE: Hao's comments removed for brevity)
class PropertyVoodoo(type):

def __init__(cls, *a):

    for prop in cls.__properties__:

        def fget(self, _prop = str(prop)):
            s = super(cls, self)
            return getattr(s, _prop)()


        def fset(self, value, _prop = str(prop)):
            s = super(cls, self)
            return getattr(s, _prop)(value)

        setattr(cls, prop, property(fget=fget, fset=fset))

    super(PropertyVoodoo, cls).__init__(*a)

    def __setattr__(self, name, value):
        if name in cls.__properties__:
            object.__setattr__(self, name, value)
        else:
            s = super(cls, self)
            s.__setattr__(name, value)

    cls.__setattr__ = __setattr__

Note that it is, in fact, completely safe to give fget and fset the extra _prop parameters because the property() class will never explicitly pass values to them, which means they will always be the default value (that being a copy of the string referenced by prop at the time each fget and fset method was created).

Brad