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

David Gobbi david.gobbi at gmail.com
Mon May 3 10:12:26 EDT 2010


On Mon, May 3, 2010 at 7:41 AM, Brad King <brad.king at kitware.com> wrote:
>
> I think vtkVariant exists because C++ does not have runtime-typed stack
> data out of the box.  Since Python does, vtkVariant is not really needed
> for that purpose.  It "would be nice" if python scripts could just pass
> their own values and have them automatically converted to vtkVariant
> if no other overload is a better/direct match.  I'm not sure this is
> practical, but if you have time to investigate this possibility I would
> be interested in the results.

Yes, this is practical, the wrappers can check the vtkVariant
constructors to see if argument conversion is possible.  For methods
that return a vtkVariant, though, I'd prefer not to do automatic
conversion to the inner type.

> How likely is this to change the method selection result?  Might
> it affect existing scripts?

All the regression tests pass.  At least the method selection will be
consistent, previously whether a "double" vs. a "float" method was
called depended on which method came first in the header file.  Now
"double" is always preferred.  Also, for vtkObject arguments, an exact
ClassName match is preferred over a match that requires a cast.  So it
might affect existing scripts, but it's all for the better and I think
that breakage is unlikely.

> I briefly glanced through the changes you've published so far.  Overall
> it looks good from a high-level point of view.  I'm not sure when I'll
> find time to actually try building it and try out the new wrappers.
> I'm still busy preparing our switch to a branchy workflow in Git, which
> will be the preferred way for you to publish this work when it's done!

Thanks for taking a look.

   David



More information about the vtk-developers mailing list