----- Original Message ----- > From: "Dominic Evans" <[email protected]> > To: [email protected] > Sent: Thursday, April 16, 2015 5:21:11 PM > Subject: Re: [RFC] Strategy for porting Proton to Python 3 > > > (Apologies for top post, on iPhone) > > #4 keep all the unittest source as python2 code for testing python2 and > jython, but also run 2to3 over it at build time to automatically produce a > version in python3 syntax?
Interesting, I didn't think of the 'on the fly' conversion approach. This is definitely worth looking at - I'll hack around a bit and see where it goes. To be honest I'm not sure of the actual extent of these types of incompatibilities. From a quick grep, there's only about a half dozen uses of 'except x, e:' in the test code. There are probably other issues I haven't found yet, but it might make sense to dig in a bit and determine the extent of the incompatibilities. If there's only a few specific instances then maybe some extra wrappers + conditional imports could solve this without turning the codebase into a freakshow. I'll try a few hacks and see if I can work out something reasonable. thanks > > > On 16 Apr 2015, at 20:40, Ken Giusti <[email protected]> wrote: > > > > And within moments, I hit my first Really Big Problem: > > > > Jython > > > > Yep, turns out Jython can't parse 'futurized' python code. Especially > dislikes the > > > > except <exception>, <var> ---> except <exception> as <var> > > > > change. Which isn't very helpful, since the 'as' variant is the only > syntax supported by Python 3 (that comma-syntax has been removed). > > > > This makes porting the python unit tests to python3 a no go. The > non-test python stuff, like the bindings and examples, are not run under > jython so it's not a problem there. > > > > So what to do? > > > > Here's a couple of options that I can think of: > > > > 1) don't port the tests to python 3. > > > > 2) create two copies of the python tests, one 'old' copy for running > under jython, and a new copy for running under python2 and 3. Remove the > old tests once jython can handle the modern syntax. > > > > 3) Stop running jython tests > > > > 4) A better idea I haven't thought of yet. > > > > I'm pretty much against option 1 - we need to be able to test the > bindings under python 3. I'm open to the others, especially #4. > > > > Opinions? > > > > -K > > > > > > > > > > ----- Original Message ----- > > > From: "Ken Giusti" <[email protected]> > > > To: [email protected] > > > Cc: "Dominic Evans" <[email protected]> > > > Sent: Thursday, April 16, 2015 9:54:35 AM > > > Subject: [RFC] Strategy for porting Proton to Python 3 > > > > > > > > > Hi all, > > > > > > I'm building on the work done by Dominic and Mickael to get all the > proton > > > python bits to work under both python2 and python3. See [1]. > > > > > > I think this will entail a lot of little changes to the python sources > and > > > the unit tests. Rather than check in a single huge patch, I'm going to > > > break it up over several patches. > > > > > > The first bunch of patches will simply 'modernize' the existing python > code. > > > Old style syntax that is not forward compatible with python 3 will be > > > replaced (eg. print "foo" --> print("foo"), etc). I'll use a tool > called > > > 'futurize' which is part of the python future toolset [2], [3]. > > > > > > Once all python code is updated, then I'll begin introducing python 3 > > > specific patches, including the work already done by Dominic and > Mickael. > > > Of course I'll verify that none of these changes will break python 2. > > > I've got a local CI system that can build/test in both environments. > > > > > > From a discussion with Dominic, we agreed that it would be A Good Thing > to > > > use one of the existing Py2 <--> Py3 abstraction libraries. These > libraries > > > provide utilities for writing code that works under both python > versions. > > > I've used 'six' in the past [4] and found it quite helpful - it will > > > eliminate a lot of the messy conditional code one has to hack in order > to > > > support both languages. > > > > > > However, this library is not part of the standard python library. This > means > > > introducing a new dependency. > > > > > > Personally, I don't think this is a big deal - use of 'six' is > ubiquitous > > > among python packages. It's available freely via pypi, and though most > > > distros. > > > > > > So that's the Big Question - is everyone comfortable with this > additional > > > dependency? Does anyone have a better alternative? Has anyone ported > > > other large python codebases - what was your experience? > > > > > > thanks, > > > > > > -K > > > > > > > > > [1] https://issues.apache.org/jira/browse/PROTON-490 > > > [2] http://python-future.org/index.html > > > [3] http://python-future.org/futurize_cheatsheet.html > > > [4] https://pythonhosted.org/six/ > > > > > > -- > > > -K > > > > > > > -- > > -K > > > > -- -K
