[vtkusers] vtk and python - some questions.
Chris Myers
myers at tc.cornell.edu
Tue Oct 24 16:30:37 EDT 2000
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:
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
compatible.
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
work?
Chris
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?
==========================================================================
Chris Myers
Cornell Theory Center
--------------------------------------------------------------------------
636 Rhodes Hall email: myers at tc.cornell.edu
Cornell University phone: (607) 255-5894 / fax: (607) 254-8888
Ithaca, NY 14853 http://www.tc.cornell.edu/~myers
--------------------------------------------------------------------------
"To thine own self be blue." - Polonious Funk
==========================================================================
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
>
>
>
> _______________________________________________
> This is the private VTK discussion list.
> Please keep messages on-topic. Check the FAQ at: <http://public.kitware.com/cgi-bin/vtkfaq>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtkusers
>
More information about the vtkusers
mailing list