Re: [ggt-devel] Python interface to GMTL

[Allen B. <al...@vr...>]

Patrick Hartling wrote:
> Allen Bierbaum wrote:
> 
>> Patrick Hartling wrote:
>>
>>> I have spent many hours today working on exposing GMTL classes and 
>>> functions for use with Python, and while I have made a ton of 
>>> progress, I have reached something of an impasse.  While it is 
>>> possible to instantiate and manipulate matrices, vectors, etc. in 
>>> Python, it is not possible at this moment to read any data from 
>>> them.  The GMTL interface is built up around C++ data access idioms, 
>>> and some of those (operator[] in particular) do not translate to 
>>> Python.  The biggest issue I face is that there is no way (at this 
>>> time) to map a C-style array to Python using Boost.Python.  Even if 
>>> there were a way to do that, Python doesn't have a data structure 
>>> with exactly the same semantics as a C-style array.  The only GMTL 
>>> class that is even close to having its data be readable is 
>>> gmtl::Matrix<>, and that's only because it overloads operator(), one 
>>> of the few class operators that can be overloaded in Python.  Of 
>>> course, I can't get the relevant Boost.Python code to compile, so the 
>>> point is moot.
>>
>>
>>
>> Why can't we use python's [] operator?  Is there something about 
>> Boost::Python that prevents this overload from taking place or is the 
>> problem related to slicing?
> 
> 
> I don't know how to overload that operator.  Pyste didn't do it 
> automatically, and I have been having trouble making sense of how 
> Boost.Python does operator overloading.  My suspicion is that Python 
> itself doesn't allow that operator to be overloaded, but I could be wrong.

the python methods are:

__getitem__ __setitem___ and __delitem__

We probably only need to define the first two of them.  There may also 
be some issues to take into account to support slicing, but we could 
ignore those in the first pass at the interface.

-Allen

> 
>  -Patrick
> 
>>> To get around this, I have thought of two options:
>>>
>>>    1. Write C++ wrapper classes around all classes that store their
>>>       data internally as an array.  Access to the data values would be
>>>       granted through some member function that would just call
>>>       obj.mData[X] or whatever.
>>>    2. Add a getter method (not an overloaded operator) to the GMTL
>>>       classes in question.  For a matrix, the getter would take two
>>>       arguments.  For a vector, it would take one.  In other words, the
>>>       argument count would be dependent upon the (conceptual) dimensions
>>>       of the internal array.  I am reluctant to follow the model of
>>>       gmtl::Quat<T>::get(), however, because I think Boost.Python has a
>>>       limit to the number of parameters a method/function can take.  (I
>>>       strongly suspect it is tied to boost::function internally.)
>>>
>>> Option 1 isn't very good because I would actually have to write 
>>> wrappers for *everything* in GMTL, not just the data types.  Since 
>>> the wrapper classes couldn't be passed to GMTL functions directly, 
>>> wrappers would have to be written around those.  It might be possible 
>>> for Boost.Python to do some behind-the-scenes magic to make this 
>>> simpler, but I'm not sure.
>>>
>>> OTOH, I doubt that Option 2 will be well received by the readers of 
>>> this mailing list.  In fact, I doubt that anyone using GMTL in C++ 
>>> would even want to use a getter method when vec[2] is so much more 
>>> pleasing to the eye (for a staunch C++ programmer).
>>>
>>> With all of this in mind, I'd like to solict suggestions--or at least 
>>> get some general discussion on the topic.  I do not want to make 
>>> unilateral decisions about how GMTL is accessed from Python. 
>>> Futhermore, it's entirely possible that I am missing something in 
>>> Boost.Python or in GMTL that would simplify my efforts.
>>>
>>>  -Patrick
>>>
>>>
>>
>>
> 
> 


-- 
-- Allen Bierbaum                         al...@vr...
-- PhD Candidate             txtmsg - 515...@us...
-- VR Juggler Team                              www.vrjuggler.org
-- Virtual Reality Applications Center       www.vrac.iastate.edu