[vtkusers] vtk and python - some questions.

[David Gobbi]

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:
> 
> 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 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 
> work?  

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

--
  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