[vtkusers] Status of VTK Python 3 wrapper support

[Berk Geveci]

Ondrej's blog is pretty scary :-)

It re-emphasizes my thought that this is not a step to be taken lightly. It
will take time to get a code base working on both 2.x and 3.x and we need
to do it while continuing to support 2.x well. We also need to figure out
what the minimum x in 2.x is. It sounds like it should be at least 6 but
possibly 7 or higher.

-berk


On Wed, Aug 6, 2014 at 1:33 PM, Matthew Brett <matthew.brett at gmail.com>
wrote:

> Hi,
>
> On Wed, Aug 6, 2014 at 4:25 AM, Berk Geveci <berk.geveci at kitware.com>
> wrote:
> > Hi David,
> >
> > Sounds great. I am glad that you are hooked on the wrappers :-) You have
> > done a lot of wonderful work on them and as a big Python fan I am very
> > grateful.
> >
> > PS: Sorry for the late reply. I was on vacation.
> >
> > Best,
> > -berk
> >
> >
> > On Fri, Aug 1, 2014 at 11:30 AM, David Gobbi <david.gobbi at gmail.com>
> wrote:
> >>
> >> Hi Berk,
> >>
> >> Thanks for the insight into how this will impact your customers.  I
> wasn't
> >> suggesting the the conversion of the tests be done now, or even before
> >> the core.  And, yes, you're probably right that 2-to-3 is the way to go
> >> until
> >> the major sites are ready to switch to python3.
> >>
> >> For myself, there are two major wrapper-related tasks that have far
> higher
> >> priority than py3k:
> >>
> >> 1) wrap enum types (so that enum types can be used as method args),
> >> and also wrap namespaces, since these are blockers for some code that
> >> I want to wrap.
> >>
> >> 2) eliminate the "PyVTKClass" type, which relies on an obsolete
> metaclass
> >> mechanism (search for "Don Beaudry hack" if you're curious) and instead
> >> use python's unified type/class extension system.
> >>
> >> For #2, I'll see if I can put up a wiki page with more detail.  But I
> >> don't have
> >> time to move forward on either 1 or 2 until the fall.  And you aren't
> >> going
> >> to see me pushing for py3k, because I still have no need for it myself.
>  I
> >> just want to be involved when the conversion occurs, because wrapper
> >> stuff is fun.
>
> Just for reference, nearly all of the big scientific python projects
> (numpy, scipy, matplotlib, ipython, sympy) have switched to using a
> common code-base for Python 2 / Python 3.  [1, 2].  This now seems to
> be the standard Python advice if you want to keep Python 2
> compatibility [3] (in days gone past, the standard advice was to use
> 2to3).  The numerical Python community is likely to start switching
> over to standardizing on Python 3 fairly soon (over the next couple of
> years), and all standard numerical packages now have Python 3 support.
> In general our experience has been that when we used a compatibility
> file such as that provided by the 'six' [6] project, and with good
> tests, porting to a Python 2 / 3 compatible code base was a lot easier
> than we had feared.
>
> Cheers,
>
> Matthew
>
> [1]
> http://ondrejcertik.blogspot.com/2013/08/how-to-support-both-python-2-and-3.html
> [2]
> http://asmeurersympy.wordpress.com/2013/08/22/python-3-single-codebase-vs-2to3
> [3] https://docs.python.org/3/howto/pyporting.html
> [6] https://pypi.python.org/pypi/six
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20140807/e3417e33/attachment.html>