(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?
> On 16 Apr 2015, at 20:40, 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
>
>
>
>
> ----- 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
>
