qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Giusti <kgiu...@redhat.com>
Subject Re: [RFC] Strategy for porting Proton to Python 3
Date Thu, 16 Apr 2015 19:38:05 GMT
And within moments, I hit my first Really Big Problem:


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

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.



----- Original Message -----
> From: "Ken Giusti" <kgiusti@redhat.com>
> To: proton@qpid.apache.org
> Cc: "Dominic Evans" <dominic.evans@uk.ibm.com>
> 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


View raw message