[vtk-developers] patch for turning (almost) all VTK errors into Python exceptions

[Charl P. Botha]

On 8/5/06, Prabhu Ramachandran <prabhu_r at users.sf.net> wrote:
> >>>>> "Charl" == Charl P Botha <cpbotha at cpbotha.net> writes:
>
>     Charl> Hi there (Python)-gang, I've made a patch for VTK 5.0 which
>     Charl> will turn almost all VTK errors into Python exceptions.  It
>     Charl> works around the exception non-safety of VTK.  Have a look
>     Charl> here:
>
>     Charl> http://visualisation.tudelft.nl/~cpbotha/thingies/python_exceptions_vtk5.0.diff
>
> [...]
>     Charl> What do VTK/Python people think?  This definitely fills a
>     Charl> niche, and it could be conditionally included in VTK.  The
>     Charl> only drawback is the extra PyErr_Occurred() call after
>     Charl> every VTK method call, and of course the extra line or two
>     Charl> of Python code to set up the new vtkEventOutputWindow).
>
> This is nice, thanks.  However, does this work for errors generated by
> VTK objects that were not instantiated in Python?  Do exceptions
> "leak" in this case?  From what I can tell of the patch, the answer is
> yes.  If so is this a problem, and how big is it?


That's why it's necessary to use my vtkEventOutputWindow class.
Errors generated by VTK objects not instantiated in Python are passed
to the vtkEventOutputWindow object that is by definition instantiated
in Python.  This object re-emits these errors as ErrorEvents, which is
caught by the wrapping-layer applied handler and are turned into
Python exceptions at the end of the next method call.

So, for the 100% solution (i.e. no leaks), you do need that
vtkEventOutputWindow class.  If these patches are applied, the class
will be committed too.  See here:

http://visualisation.tudelft.nl/~cpbotha/thingies/vtkEventOutputWindow.cxx
(and .h)

It is used as follows:
eow = vtk.vtkEventOutputWindow()
eow.SetInstance(eow)

Prabhu, now that I have you on the line.  I just noticed that although
PyGILState_Ensure/Release calls are used in vtkPythonUtil.cxx (I think
I applied these patches a while back, contributed by Sander Niemeyer)
and I'm now using these calls in my ErrorEvent handler as well
(because they could be called from any C-thread), there is no call to
PyEval_InitThreads() anywhere.  I've now added it to the
vtkPythonUtil.cxx constructor.  Do you agree that this is necessary?


See you,
Charl