[vtk-developers] Wrapping vtkVariant and other special types in Python

David Gobbi david.gobbi at gmail.com
Sun May 2 20:41:21 EDT 2010


Hi Berk,

It's a new python class, and from python it doesn't look like a native
type.  No operators are wrapped.  It was my original plan was to make
it look like a native type, but then I decided that it would be more
useful (and easier) to add "generic" class wrapping to
vtkWrapPython.c.  By this I mean that with the new wrappers, pretty
much any un-templated non-vtkObject class can be wrapped by setting
the "WRAP_SPECIAL" property for that class in CMake.  But only methods
are wrapped, not operators.

Is making it look like a native type a hot item on the wish list?
Operators are actually parsed by the vtkParse front end, but right now
the back-ends like vtkWrapPython.c are ignoring them.

  David


On Sun, May 2, 2010 at 6:08 PM, Berk Geveci <berk.geveci at kitware.com> wrote:
> Hi David,
>
> I apologize if this was already answered. Are you mapping vtkVariant
> to a new Python class or a native Python type? If it is a new
> class/type, is it compatible with other types? For example, if the
> variant contains an int, can I do variant + 5?
>
> -berk
>
> On Sun, May 2, 2010 at 5:21 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>> As suggested by Brad, I've made a fork of VTK on github and pushed my
>> wrapper changes to it:
>> http://github.com/dgobbi/VTK
>>
>> This version of VTK wraps vtkVariant for Python, and should be capable
>> of wrapping many other special types as well.  In
>> Common/CMakeLists.txt you can see where I've added a "WRAP_SPECIAL"
>> property for vtkVariant and vtkTimeStamp.  Other classes can be given
>> the WRAP_SPECIAL property as well, and I encourage people to try.
>> Note that after adding the WRAP_SPECIAL property to a class, you'll
>> have to play with BTX/ETX.
>>
>> I haven't started in on the vtkStdString fixes yet.  It is a separate
>> issue in a way, because vtkStdString and vtkUnicodeString are
>> "fundamental types" as far as the wrappers are concerned, while
>> vtkVariant is merely a "special type."  Apologies for using my own
>> made-up vocabulary here. In any case, if I fix the vtkStdString
>> wrapping, it will be fixed across all the wrapper languages, not just
>> python.
>>
>> In addition to special type support for python and massive cleanup of
>> vtkWrapPython.c, I've also changed the way that overloaded functions
>> are resolved.  The python wrappers used to try each overload in turn
>> until one of them worked.  Now the python wrappers find the overload
>> that is the best match to the arguments.
>>
>> And one more item before I head outdoors to enjoy what's left of the
>> weekend: I've finally pushed the WrapVTK project out to github,
>> http://github.com/dgobbi/WrapVTK, which can be used to generate XML
>> descriptions of the VTK classes.  WrapVTK will be used as the basis
>> for the next version of the SimVTK (Simulink/VTK) project.
>>
>> Any feedback is appreciated.
>>
>>   David
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.vtk.org/mailman/listinfo/vtk-developers
>>
>>
>



More information about the vtk-developers mailing list