[Insight-users] Adding Python typemap for scalars returned by reference

[Charl P. Botha]

Dear list,

As reported recently, we see things like this in the ITK Python
wrappings:

In [3]: registration = itk.itkImageRegistrationMethodF2F2_New()
In [4]: registration.GetLastTransformParameters().GetElement(0)
Out[4]: '_e8c8b708_p_double'
In [5]: registration.GetLastTransformParameters().GetElement(1)
Out[5]: '_f0c8b708_p_double'

So, instead of just showing me the numbers, I get to see the SWIG type
_p_double.  This is because the C++ method
itkArray<TValueType>::GetElement returns a TValueType&, i.e. a C++
reference.  SWIG reduces this to a pointer, which is why we don't see
the values themselves above.  We *COULD* use DArray_getitem() to get the
value, however:

If I were to add typemaps such as the following to itk.swg:
%typemap(out)  double &, float &
        "$result = PyFloat_FromDouble((double) *($1));";

GetElement() will return an actual double in Python as well.  The
DISADVANTAGE is that we can't use DArray_setitem() anymore on that
specific item.  However, itkArray does have a SetElement() method, so
that's no problem.

Such a typemap will do the same for ALL double& and float& returns: if
there's no corresponding Set*() call for a particular class, it could
pose a problem.

I propose adding the typemap to make the Python calls act more naturally
and adding Set*() methods for those ITK classes that really need them
because of the typemap change.  I don't believe we'll require too much
of the latter.

Should I go ahead and add these typemaps?  Does anyone have any other
ideas?

Thanks for any input,
Charl

-- 
charl p. botha http://cpbotha . net/ http://visualisation . tudelft . nl/