[vtkusers] Status of VTK Python 3 wrapper support

[Dov Grobgeld]

Is there a conversion document describing how the "look and feel" of the
new binding?

The current binding is very non-pythonesque in various ways. E.g.:

import vtk
# identity transformation
t = vtk.vtkTransform()
in_point = (1,0,0)
out_point = [0,0,0]
t.TransformPoint(in_point,out_point)
# would expect something like
in_point = vtk.vtkPoint((1,0,0))
out_point = t.TransformPoint(in_point)

There are lots of other examples as well that I encountered in the source.
E.g. the use of gettattr() and a dispatcher, instead of just using the
standard python list of class methods.

Of course, such a drastic change this will break the current API. But you
can always call it vtk6 and decide not to be backwards compatible.

Regards,
Dov


On Fri, Aug 1, 2014 at 10:21 AM, Arnd Baecker <arnd.baecker at web.de> wrote:

> On Thu, 31 Jul 2014, David Gobbi wrote:
>
>  On Thu, Jul 31, 2014 at 6:44 AM, diego0020 <da.angulo39 at uniandes.edu.co>
>> wrote:
>>
>>>
>>> But I am also looking forward to this. Is there anything we could do to
>>> push
>>> support for python 3 forward?
>>>
>>
>> There has been some discussion about converting all of the python
>> tests and examples, which is a part of the process where extra
>> manpower would be a big asset.  I imagine that the conversion will
>> go something like this:
>>
>> 1) Someone will run 2to3 on all the python code, and then make
>> sure that it can be byte-compiled with python3 (it will be too early
>> at this stage to actually run the code, but making sure that it
>> byte-compiles will be a good first step).
>>
>> 2) Lots of people will then pick through the code to fix conversion
>> errors and to make sure that the code actually looks like good
>> python3 code.
>>
>> 3) Finally, someone will add some CMake magic to VTK so that if VTK
>> is built against python2, cmake will run 3to2 on all of these new python3
>> files and put the equivalent python2 code into the VTK build
>> directory.  This is the magic that is needed to make sure that VTK
>> will be able to support both python2 and python3.
>>
>> So any assistance with the above process would be a big help.  In
>> particular, it would be very useful if someone could verify that item
>> (3) is even feasible: in the end it might be necessary to have hand-
>> written python2 and python3 exist side-by-side instead of using
>> automatic conversion.  It _should_ be feasible, since the VTK
>> tests used automated tcl-to-python conversion for many years,
>> and python3 to python2 should be much easier than tcl to python.
>>
>
> As a disclaimer ahead: I don't have any experience in porting
> to python 3. For my own projects I am just trying to follow pylint's
> suggestions about possible python 3 problems and using
> ``from __future__ import (division, print_function)`` at the beginning.
>
> According to https://docs.python.org/2/howto/pyporting.html
> it might be worth a try to run the examples/tests with the ``-3``
> option to find out about possible compatibility problems.
> I tried this with some random examples and no problems were
> reported.
> So it might be that a lot of code is such
> that it would work fine both with python 2 and python 3.
> (Maybe someone from the numpy/scipy/... experts could
> also help with their experience in supporting both python 2 and 3).
>
> Unfortunately at the moment I won't have time to look into this
> further, but I will try to help, if needed.
>
> Best, Arnd
>
>
>
>
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Please keep messages on-topic and check the VTK FAQ at:
> http://www.vtk.org/Wiki/VTK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtkusers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20140801/14f0dcd9/attachment-0001.html>