ANN: pyparsing 1.5.1 released
rtw at freenet.co.uk
Sun Oct 19 15:16:13 CEST 2008
Paul McGuire wrote in
news:bf450d6b-aaa1-4a16-8ea4-1770a37164e3 at y21g2000hsf.googlegroups.com
> On Oct 18, 1:05 pm, Terry Reedy <tjre... at udel.edu> wrote:
>> Paul McGuire wrote:
>> > I've just uploaded to SourceForge and PyPI the latest update to
>> > (Python 3.0 uses syntax for catching exceptions that is
>> > incompatible with Python versions pre 2.6, so there is no way for
>> > me to support both existing Python releases and Python 3.0 with a
>> > common source code base.
>> I thought 2to3.py was supposed to make that change automatically.
>> Have you tried it and found it not to work?
> Please re-read my caveat. What I said was (or tried to anyway) was
> that I cannot write a source file that will work on 2.4, 2.5, 2.6, and
> 3.0. Actually, it was very close - but for the change in the "except"
> syntax, I could actually have pulled it off.
> I should probably use 2to3.py on my unit tests, so that my Py3 version
> of pyparsing can get tested more fully. I'll also use 2to3.py on
> pyparsing.py itself, it will make it easier to maintain the Py3 source
> version. (I'll still have to keep and support two different source
> versions though, pity.)
AIUI the idea is that you write your 2.x python code (and tests) so
that when they are processed by 2to3.py you get valid python 3.x
code that will pass all its tests.
You then maintain your 2.x code base adding another test where the
code (and tests) is run through 2to3.py and then python 3.x runs
the test suite.
Presumably you only need to start maintining a 3.x code base when
you start adding 3.x specific features or abandon support for
More information about the Python-list