[vtkusers] vtk and python - some questions.

[David Gobbi]

On Thu, 9 Nov 2000, Prabhu Ramachandran wrote:

> hi,
> 
> >>>>> "David" == David Gobbi <dgobbi at irus.rri.on.ca> writes:
> 
>     David> Hi Prabhu, I've made some massive changes to the python
>     David> wrappers that should be useful to you.  They'll appear in
>     David> the nightlies tomorrow (they're already in CVS).
> 
> Wow! and thanks a ton!!  I really appreciate your efforts.

It actually didn't take as long as I expected, a day and a half of
my weekend.    
 
> <snipped greatly appreciated new features etc.>
> 
>     David> The new VTK/Python classes and objects have a similar 'look
>     David> & feel' to Python's own classes and class instances,
>     David> however, you cannot derive a Python class from a VTK/Python
>     David> class unless you write your own wrapper class.
> 
> Having complained about the python bindings, I, for my part, have
> figured out how to use py_cpp, and actually have managed to wrap (with
> a TON of help from the py_cpp developer - David Abrahams) the
> vtkObject class.  There were and still are a few issues with vtk's
> reference counting and python's.  I have a small fix but more on that
> later.

You're lucky that he doesn't get grouchy as easily as I do ;) 

> As far as the py_cpp wrapped vtkObject class goes, it is easy to code,
> behaves as a true python object under python and allows one to
> override virtual functions of the original c++ class and requires no
> shadow python class.  This paragraph from the py_cpp docs explains
> this much better.
> 
>       "Another obstacle that most people run into eventually when
>       extending Python is that there's no way to make a true Python
>       class in an extension module. The typical solution is to create
>       a new Python type in the extension module, and then write an
>       additional module in 100% Python. The Python module defines a
>       Python class which dispatches to an instance of the extension
>       type, which it contains. This allows users to write subclasses
>       of the class in the Python module, almost as though they were
>       sublcassing the extension type. Aside from being tedious, it's
>       not really the same as having a true class, because there's no
>       way for the user to override a method of the extension type
>       which is called from the extension module. ..."

I've thought of ways that this could be done, by deriving a special
C++/Python class for each underlying C++ class and adding a static
Python wrapper method to the class for each C++ method (plus add code
to deal with ivars), but the way I've imagined it it would require much
more wrapper code than the current wrappers.  Already, there is 50% more
python wrapper code than there is VTK code!  Maybe py_cpp uses a smarter
method that is more efficient.

> Py_cpp does not suffer this problem.  Which in plain english means,
> that not only can I wrap the vtkObject class (or any other class) to a
> python class, I can override virtual methods of the class and the c++
> code will think that the python class is a subclass written in c++ for
> all practical purposes!!  It works, although I have not _really_
> tested it because I dont have any other vtk classes that I have
> wrapped.
> 
> I am going to be busy for the next week or so, but already have
> started some work on automated generation of wrapper code (using the
> stuff in wrap/ and python).  Hopefully, if everything goes well, I
> will have something to really shout about in a few weeks. :)

Well, keep going!  There are going to be plenty of people who will want
to use it.

> David, thanks for all your efforts.  I really appreciate it.  My
> present work on py_cpp is not to dampen your spirits or compete with
> your efforts.  It is unlikely that the first py_cpp based wrapping
> will be anywhere as good as the current python bindings but this is my
> shot at getting the best possible python wrappers for vtk.

What's wrong with a little competition ;)  I'll continue working on
the current python wrappers until I decide that they're obsolete.

 - David

--
  David Gobbi, MSc                    dgobbi at irus.rri.on.ca
  Advanced Imaging Research Group
  Robarts Research Institute, University of Western Ontario