[vtkusers] vtk and python - some questions.
dgobbi at irus.rri.on.ca
Tue Oct 24 17:03:15 EDT 2000
On Tue, 24 Oct 2000, Chris Myers wrote:
> This is somewhat tangential to the main thread regarding VTK, Python
> and SWIG, but it is related.
> One thing that could be useful would be the ability to intermingle
> SWIG-wrapped Python/VTK objects and the native VTK-wrapped Python/VTK
> objects. For example, one might have a C++ subroutine that does a
> bunch of things and, at the end, returns a VTK object, such as a
> vtkUnstructuredGrid *makeUnstructuredGrid();
> Within SWIG, one can wrap this function so that the makeUnstructuredGrid
> function can be called from within Python, and a SWIG-wrapped opaque
> pointer to the vtkUnstructuredGrid is returned:
> >>> grid = makeUnstructuredGrid()
> # grid is now a SWIG-wrapped python object that owns a SWIG-pointer
> # to the underlying C++ object
> Now, one might want to pass this grid on down the VTK/Python pipeline:
> >>> mapper = vtkDataSetMapper()
> >>> mapper.SetInput(grid)
> The problem is that VTK and SWIG have wrapped up the underlying object
> in different ways. If SWIG had wrapped the vtkDataSetMapper() call
> also, then it would be able to pass the grid pointer to the mapper
> SetInput method in a consistent fashion. I have not found a way to
> convince the pre-existing VTK-wrapped Python objects to accept SWIG-wrapped
> pointers, even though at the level of the Python-C API they should be
The solution to this problem is actually very straightforward. Already
the python wrappers are capable of taking an address of an arbitrary
vtkObject and creating a matching VTK-python object. I would just have
to make this function available from the Python side.
IIRC, SWIG can do the same so VTK-python objects should have a method for
getting the SWIG-mangled pointer of the underlying vtkObject.
> The solution to this, of course, is not to use SWIG, but instead wrap
> the makeUnstructuredGrid() function live within the VTK hierarchy (e.g.,
> by custom-building a new vtkUnstructuredGridSource object and installing
> it in the local VTK library). In some cases, it might be quicker and
> easier to have SWIG its own shared object module that can live outside
> of the VTK library structure, but still play with VTK.
> Has anybody thought about such things, or how they might be made to
I can do better than that... if you can promise me that you can test it,
I'll modify the VTK-Python wrappers to make it possible. It would
be implemented as a type-cast operation, i.e.
newObject = vtkObject(<SWIG-mangled-ptr>)
> P.S. Having looked at the VTK introspection code that Prabhu wrote to
> implement his VTK-CFD, I can understand his frustration with the lack
> of certain features in the Python/VTK interface. SWIG-wrapped objects
> can be examined, for example, through the __class__ and __bases__
> attributes, to reconstruct available methods for those objects. I dug
> around in the Python/C API a bit trying to understand this better when
> Prabhu was asking a few months ago about introspection-related matters,
> but I don't recall reaching any real conclusions. Are there attributes
> of python objects that could be incorporated into the existing VTK/Python
> wrappers without introducing too much extra code?
I've thought about this but haven't written any code. It is certainly
do-able, and wouldn't add much extra weight to the wrappers. It just
hasn't been done <yet>.
David Gobbi, MSc dgobbi at irus.rri.on.ca
Advanced Imaging Research Group
Robarts Research Institute, University of Western Ontario
> On Tue, 24 Oct 2000, David Gobbi wrote:
> > Date: Tue, 24 Oct 2000 14:06:45 -0400 (EDT)
> > From: David Gobbi <dgobbi at irus.rri.on.ca>
> > To: Prabhu Ramachandran <prabhu at cyberwaveindia.com>
> > Cc: VTK users list <vtkusers at public.kitware.com>
> > Subject: Re: [vtkusers] vtk and python - some questions.
> > On Tue, 24 Oct 2000, Prabhu Ramachandran wrote:
> > > hi,
> > >
> > > I sent this message on Friday but I have no idea why it didnt
> > > show up on the list. Please excuse me if the original mail actually
> > > shows up again later! :)
> > >
> > > My following paragraph may sound offensive, please do not take
> > > it personally. I am merely stating the state of affairs as I see
> > > them.
> > >
> > > As the python vtk users are aware, the vtk bindings for python
> > > are far from perfect. They certainly function and one can work around
> > > some of the problems and actually do pretty nice things. However,
> > > there are a large number of things that are not ok. Primarily, the
> > > vtk python objects do not behave as proper python objects at all.
> > The same is true for all of Python's internal types. A python list, for
> > example, is not a python 'object' and doesn't behave the same way as one.
> > There have been many discussions on comp.lang.python in regards to this
> > issue (the 'type vs. class' issue).
> > SWIG gets around this by creating a 'wrapper' class (written in python)
> > to supplement the underlying Python type. I really don't think this is
> > a good idea for VTK -- the python wrappers already include a huge amount
> > of C++ code... about as much Python code (in addition to the existing C++)
> > would be neccesary to create 'proper' python objects.
> > > I believe that at one time SWIG (www.swig.org) was used to
> > > generate the wrappings. What were the problems with swig and why is
> > > it not used any more?
> > As someone else replied, this was never true. Here are the reasons for
> > not using SWIG:
> > 1) the current release of SWIG doesn't have a complete C++ parser, and
> > can't be made to understand the macros in vtkSetGet.h
> > 2) because SWIG generates both C++ and Python code for the wrapper
> > classes, it would generate more (and less efficient) wrappers than
> > the current VTK wrapper generators
> > 3) it wouldn't make sense to use SWIG just for the Python wrappers,
> > it is very important (from a maintenance standpoint) that the wrappers
> > for the different languages are generated in a consistent manner, to
> > ensure that it isn't too much of a hassle for Ken, Will et all to
> > deal with when they have to
> > > There are quite a few new tools that help making proper python
> > > bindings for c++ libraries. ExtensionClass, CXX etc. come to mind.
> > > Most notably, there is a new tool called py_cpp (the name may change)
> > > that eases wrapping c++ classes to python. py_cpp is under active
> > > development and is available here
> > >
> > > http://people.ne.mediaone.net/abrahams/downloads/py_cpp.html
> > >
> > > I was wondering if we could use py_cpp and modify the current
> > > wrapper scripts to use it automatically. Would this be possible to
> > > do? If it is, could someone in the know please provide some hints on
> > > the auto generation of wrappers? One has to typically write very
> > > little boilerplate code to wrap the classes. One does require the
> > > boost libraries though.
> > See point (3) above. Here are two questions for you:
> > 1) If it is easy to use these tools to generate Python wrappers for VTK,
> > then why not provide us with a demonstration? I really would like to
> > see better Python wrappers, myself.
> > 2) If you are concerned about the quality of the existing Python wrappers,
> > why not take the time to contribute improvements to them? You've
> > provided several great suggestions in the past, but I've only had time
> > implement a couple of them myself.
> > You've contributed a great deal to the VTK community in the past (and
> > please continue to do so!) and I certainly didn't write this to dampen
> > your desire to improve the python/VTK situation! But for now, I'm going
> > to continue to focus on the existing Python wrappers until I am
> > presented with an alternative set of operational Python/VTK wrappers.
> > - David
> > --
> > David Gobbi, MSc dgobbi at irus.rri.on.ca
> > Advanced Imaging Research Group
> > Robarts Research Institute, University of Western Ontario
More information about the vtkusers