[vtkusers] Status of VTK Python 3 wrapper support
berk.geveci at kitware.com
Thu Aug 7 09:20:39 EDT 2014
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.
On Wed, Aug 6, 2014 at 1:33 PM, Matthew Brett <matthew.brett at gmail.com>
> On Wed, Aug 6, 2014 at 4:25 AM, Berk Geveci <berk.geveci at kitware.com>
> > 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>
> >> Hi Berk,
> >> Thanks for the insight into how this will impact your customers. I
> >> 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
> >> 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
> >> 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.
> >> 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  (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'  project, and with good
> tests, porting to a Python 2 / 3 compatible code base was a lot easier
> than we had feared.
>  https://docs.python.org/3/howto/pyporting.html
>  https://pypi.python.org/pypi/six
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the vtkusers