ANN: pyparsing 1.5.1 released

[Paul McGuire]

I've just uploaded to SourceForge and PyPI the latest update to
pyparsing, version 1.5.1. It has been a couple of months since
1.5.0 was released, and a number of bug-fixes and enhancements
have accumulated in SVN, so time for a release!

Here's what's new in Pyparsing 1.5.1:

- Added __dir__() methods to ParseBaseException and ParseResults,
to support new dir() behavior in Py2.6 and Py3.0. If dir() is
called on a ParseResults object, the returned list will include
the base set of attribute names, plus any results names that are
defined.

- Added new helper method originalTextFor, to replace the use of
the current keepOriginalText parse action. The implementation
of originalTextFor is simpler and faster than keepOriginalText,
and does not depend on using the inspect or imp modules.

- Added failOn argument to SkipTo, so that grammars can define
literal strings or pyparsing expressions which, if found in the
skipped text, will cause SkipTo to fail. Useful to prevent
SkipTo from reading past terminating expression. Instigated by
question posed by Aki Niimura on the pyparsing wiki.

Pyparsing 1.5.1 also includes these bug-fixes (more details in
the CHANGES file included with the source distributions):

- Fixed bug in nestedExpr if multi-character expressions are given
for nesting delimiters.

- Removed dependency on xml.sax.saxutils.escape, and included
internal implementation instead.

- Fixed typo in ParseResults.insert.

- Fixed bug in '-' error stop, when '-' operator is used inside a
Combine expression.

- Reverted generator expression to use list comprehension, for
better compatibility with Python 2.3.

- Fixed bug in parseString(parseAll=True), when the input string
ends with a comment or whitespace.

- Fixed bug in LineStart and LineEnd that did not recognize any
special whitespace chars defined using ParserElement.setDefault-
WhitespaceChars.

- Forward class is now more tolerant of subclassing.

(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. For those who wish to try out pyparsing with Python 3.0, there
is a file pyparsing_py3.py in the SourceForge Subversion repository.
I have done some testing of this code, but many of my unit tests
still
need to be converted to Python 3.)

Download pyparsing 1.5.1 at http://sourceforge.net/projects/pyparsing/.
The pyparsing Wiki is at http://pyparsing.wikispaces.com

-- Paul

========================================
Pyparsing is a pure-Python class library for quickly developing
recursive-descent parsers. Parser grammars are assembled directly in
the calling Python code, using classes such as Literal, Word,
OneOrMore, Optional, etc., combined with operators '+', '|', and '^'
for And, MatchFirst, and Or. No separate code-generation or external
files are required. Pyparsing can be used in many cases in place of
regular expressions, with shorter learning curve and greater
readability and maintainability. Pyparsing comes with a number of
parsing examples, including:
- "Hello, World!" (English, Korean, Greek, and Spanish)
- chemical formulas
- configuration file parser
- web page URL extractor
- 5-function arithmetic expression parser
- subset of CORBA IDL
- chess portable game notation
- simple SQL parser
- Mozilla calendar file parser
- EBNF parser/compiler
- Python value string parser (lists, dicts, tuples, with nesting)
(safe alternative to eval)
- HTML tag stripper
- S-expression parser
- macro substitution preprocessor
- TAP output parser

 

[Terry Reedy]

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?

tjr

 

[Paul McGuire]

I thought 2to3.py was supposed to make that change automatically. Have
you tried it and found it not to work?

tjr

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.)

-- Paul

 

[Benjamin]

(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.  For those who wish to try out pyparsing with Python 3.0, there
is a file pyparsing_py3.py in the SourceForge Subversion repository.
I have done some testing of this code, but many of my unit tests
still
need to be converted to Python 3.)

As mentioned above it should be easy to convert this at release time
by running "2to3 -f except pyparsing.py". (Do tell me if you have any
feedback; I'm maintaining it at the moment.)

 

[Terry Reedy]

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
2.x python.

http://wiki.python.org/moin/Early2to3Migrations

reports some early experiences (some a year old). Martin's was edited
most recently, but even his report misses recent changes to 2to3.