FAQ
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

Search Discussions

  • Terry Reedy at Oct 18, 2008 at 6:05 pm

    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?

    tjr
  • Paul McGuire at Oct 19, 2008 at 7:22 am

    On Oct 18, 1:05?pm, Terry Reedy 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?

    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
  • Rob Williscroft at Oct 19, 2008 at 1:16 pm
    Paul McGuire wrote in
    news:bf450d6b-aaa1-4a16-8ea4-1770a37164e3 at y21g2000hsf.googlegroups.com
    in comp.lang.python:
    On Oct 18, 1:05?pm, Terry Reedy 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?

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

    Rob.
  • Terry Reedy at Oct 20, 2008 at 6:12 am

    Rob Williscroft wrote:

    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.
  • Benjamin at Oct 20, 2008 at 2:51 am

    On Oct 17, 11:14?pm, Paul McGuire wrote:
    (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.)
  • Oyster at Oct 20, 2008 at 5:54 am
    but the pyparsing.py in pyparsing-1.5.1.tar.gz is marked as 2008-10-02
    I think it is good too touch all the files' time up-to-date.
  • Marc 'BlackJack' Rintsch at Oct 20, 2008 at 7:30 am

    On Mon, 20 Oct 2008 13:54:56 +0800, oyster wrote:

    but the pyparsing.py in pyparsing-1.5.1.tar.gz is marked as 2008-10-02 I
    think it is good too touch all the files' time up-to-date.
    Why? This throws away information, such as "when was package/module xy
    changed".

    Ciao,
    Marc 'BlackJack' Rintsch

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppython-list @
categoriespython
postedOct 18, '08 at 4:14a
activeOct 20, '08 at 7:30a
posts8
users6
websitepython.org

People

Translate

site design / logo © 2022 Grokbase