On 16 April 2015 at 20:38, 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 > >
We are using jython 2.5.3, which is the current 'final' release, however on checking the site there have been a couple of RCs for 2.7 in the last month that suggest it might actually be nearing completion (it has been baking slowly for a couple of years since an initial beta), so perhaps we could look to upgrade to bring support for 'as'. > > > ----- 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
