[vtkusers] Status of VTK Python 3 wrapper support
dov.grobgeld at gmail.com
Fri Aug 1 04:41:20 EDT 2014
Is there a conversion document describing how the "look and feel" of the
The current binding is very non-pythonesque in various ways. E.g.:
# identity transformation
t = vtk.vtkTransform()
in_point = (1,0,0)
out_point = [0,0,0]
# 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.
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>
>>> But I am also looking forward to this. Is there anything we could do to
>>> 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
> 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/
> Please keep messages on-topic and check the VTK FAQ at:
> Follow this link to subscribe/unsubscribe:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the vtkusers