Re: [ggt-devel] Python interface to GMTL

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

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?

-Allen

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