On 16 April 2015 at 20:38, Ken Giusti <kgiu...@redhat.com> 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" <kgiu...@redhat.com>
>> To: proton@qpid.apache.org
>> Cc: "Dominic Evans" <dominic.ev...@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
>>
>
> --
> -K

Reply via email to