[vtkusers] Making the python binding more pythonesque

[David Gobbi]

On Sat, Feb 15, 2014 at 11:39 PM, Dov Grobgeld <dov.grobgeld at gmail.com> wrote:
> Thanks for the reply, David. I had a look yesterday at the vtk python
> binding sources and I was confused by the levels of complexity. Why do you
> need PyVTKCLass at all? Why isn't each wrapped vtk class assigned to its own
> PyObject derivation? Why all the extra attribute lookup at run time?

Have you read the VTK wiki pages on wrapping yet?  They'll answer some
(but not all) of your questions.

The PyVTKClass and PyVTKObject were written over 10 years ago to
support old-style python classes.  In the days of old-style classes,
it was much simpler (and more efficient) to simply have one python
"class" type and one python "object" type for VTK.  Back then, the
sole responsibility of vtkWrapPython.c was to generate methods for
each VTK class.

Eventually, PyVTKClass and PyVTKObject will be removed, and all VTK
classes are wrapped as new-style python classes.  But I wasn't
planning to do this until it becomes necessary to support Python 3.
And that probably won't happen for another one or two years.

The use of GetAttr for methods will probably also go away once the
wrappers switch everything to new-style classes.  However, not that
even if there weren't special GetAttr methods, python's default does
almost exactly the same thing internally to do the method lookups.

> I recently finished a large pyhton binding of a C++ class, see
> https://github.com/dov/hirsch . I autogenerated the python code based on the
> h-headers, but also left in several points in the process for manual
> tweaking. At the moment I don't really see how the same approach can be done
> to the current vtk python binding.

I do not think that the use of something like CppHeaderParse is a good
idea for VTK.  Right now, one of the huge advantages of the VTK
wrapper tools is that they have no dependencies.  A person does not
have to download any extra packages in order to build the VTK wrapper
tools.

With respect to the iterator and sequence protocols: because
vtkDataArray is currently wrapped as an old-style python class, the
best way to add these protocols is probably to add __iter__(),
__getitem__(), etc. methods to the class.  It should be possible to do
this from the python side, by adding these new methods to the dict of
the class.

  David

> On Sat, Feb 15, 2014 at 9:34 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>
>> Hi Dov,
>>
>> I'll answer in reverse order.  Patches are submitted via gerrit, which
>> is a web-based git review tool.  Some details are here:
>>
>> http://www.vtk.org/Wiki/VTK/Git/Develop
>>
>> The VTK wrapper-generation tools are written in C because,
>> historically, lex and yacc only worked with C (the VTK wrappers
>> were first written back in the 1990's).  For my part, at least, I find it
>> much easier to simply modify and improve what is already there,
>> rather than re-write the wrapper tools in a new language.
>>
>> Yes, the python wrappers are generated by vtkWrapPython.c.  It
>> isn't very well documented, but all the documentation that exists is
>> on the VTK wiki (just do a google of "vtk wrappers" and you'll find
>> all the relevant wiki pages).
>>
>> I think that supporting the iterator and sequence protocols is a good
>> idea, and I'd be willing to review the change.  The VTK arrays already
>> support the old buffer protocol (see PythonCore/PyVTKObject.cxx).
>>
>>   David
>>
>> On Sat, Feb 15, 2014 at 11:41 AM, Dov Grobgeld <dov.grobgeld at gmail.com>
>> wrote:
>> > I've been thinking about how to make the vtk python binding more
>> > pythonesque? Here are a couple of examples and what I have in mind:
>> >
>> > Current syntax:
>> >
>> > # poly is vtkPolyLine
>> > num_points = poly.GetNumberOfPoints()
>> > pts = c.GetPoints()
>> > for i in range(num_points):
>> >    p = pts.GetPoint(i)
>> >    foo(p)
>> >
>> > New syntax:
>> >
>> > for p in poly:
>> >    foo(p)
>> >
>> > Needed change:
>> >
>> > For all vtk array like objects, support python sequence iterator API
>> > tp_iter
>> > and tp_iternext.
>> >
>> > Current syntax:
>> >
>> > pts = c.GetPoints()
>> > p1 = pts.GetPoint(0)
>> > p2 = pts.GetPoint(1)
>> > p3 = pts.GetPoint(2)
>> > norm = [0,0,0]
>> > vtk.vtkTriangle.ComputeNormalDirection(p1,p2,p3,norm)
>> >
>> > New syntax:
>> >
>> > norm = vtk.vtkTriangle.ComputeNormalDirection(c.GetPoints()[0:3])
>> >
>> > Needed change:
>> >
>> > Support sequence methods sq_length, sq_concat, sq_item, sq_slice,
>> > For all methods returning values, if the arguments only contain the
>> > number
>> > of input parameters, return the result in a python tuple.
>> >
>> > Please let me know if you would accept patches for implementing the
>> > above
>> > behavior.
>> >
>> > I would also appreciate a description of the mechanism for the
>> > autogeneration of the python binding. I assume that
>> > VTK/Wrapping/Tools/vtkWrapPython.c is used. (Btw, why is it written in c
>> > and
>> > not in C++ (or even python)?)
>> >
>> > And finally, what is the proper way of submit patches? Is a pull request
>> > on
>> > github accepted?
>> >
>> > Regards,
>> > Dov
>
>