[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