[C++-sig] boost.python - C++ class overridden in python causes slicing

[troy d. straszheim]

Jean-Sébastien Guay wrote:
> Hello Troy,
> 
>> I've been doing a bunch of work with osg recently.  I like it and 
>> badly  miss some boost.python bindings.  I'd be very interested to 
>> have a look at the code here, maybe pitch in a bit.  Is there a git 
>> archive I can clone, and a failing test I can run?
> 
> I was thinking of setting up a googlecode project for this work, because 
> there is at least one other person who might be interested in working 
> with me on it (Paul Melis). I'll see if I can do that soon.
> 
> I prefer to work with svn though (used to be CVS was oldschool, now it's 
> SVN, I know I'm behind the times), hope that's not a problem for you.

Doesn't really matter to me.

> I would have liked to get the basic functionality working before setting 
> that up because there's already another project trying to wrap OSG to 
> python (osgSwig), so I'd like to be able to prove that my solution is 
> competitive with that one.

Competitive isn't an issue, as swig and boost.python bindings aren't 
really compatible (or is that 'sip' bindings that aren't compatible?). 
Personally I prefer a manual approach over automatically generated 
bindings; apparently for the same reasons that some compiler writers 
insist on handwritten recursive descent parsers.  I know there are smart 
people around that have worked long and hard on generators, I don't want 
to start any fights.  YMMV.

> For reference, osgSwig have been having trouble lately wrapping the 
> classes derived (multiply) from osg::MixinVector<T>, and have relied on 
> patches to OSG that remove that derivation (essentially going back to 
> the OSG 2.6 versions of those classes). On the other hand, using 
> boost.python I can wrap things as I want, and I don't have any problem 
> wrapping classes derived from MixinVector<T>, so I think it's a better 
> route in the long run.

Yes exactly.  Being intrusive is just not an option, for one.  More 
examples are easy to come up with, e.g. wants fine-grained control over 
the python interface to provide things like conversions to native python 
types (datetime, numpy arrays), or to provide slicing notation and 
iterators on a node's children, say

    node.children[2:7]

> Anyways, yeah, I'll set up that project so you can run the actual code 
> and see the problem firsthand, hopefully that will make it easier to 
> help out.

Looking forward to it.

-t