Re: [ggt-devel] Python interface to GMTL

[Patrick H. <pa...@13...>]

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.

  -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
>>
>>
> 
> 


-- 
Patrick L. Hartling			| Research Assistant, VRAC
pa...@13...				| 2274 Howe Hall Room 2624
PGP: http://www.137.org/patrick/pgp.txt	| T: +1.515.294.4916
http://www.137.org/patrick/		| http://www.vrac.iastate.edu/