Hi Troy,
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.
Well it's not a matter of being compatible with osgSwig, I know it's one
or the other, but I prefer manual to automatically generated for the
same reasons you do (see below).
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]
Heh, I've got some types of slicing working for Vec*Array :-) Other
forms I haven't gotten to. But yeah, I want to give a python-esque view
of the OSG data structures as much as possible.
Note that I'm a C++ programmer writing python, so in most cases I don't
know what python-esque is without reading the python tutorial, but I
still have that goal :-)
J-S
--
______________________________________________________
Jean-Sebastien Guay jean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
