ANN: pyparsing-1.3.1 released

P

Paul McGuire

(sorry if this is a double-post - I tried posting this last night but I
think GoogleGroups ate it)

Pyparsing is a pure-Python class library for quickly and easily
constructing recursive-descent parsers. Pyparsing takes a
"building-block" approach to parser construction, as opposed to code
generation methods (such as lex/yacc) or pattern definition strings
(such as regular expressions).

Version 1.3.1 includes some minor enhancements, plus some performance
improvements that can really improve parsing speed for grammars that
use the Combine class (often used in specifying floating point
numbers).

The 1.3.1 change notes are listed below. Download pyparsing at
http://pyparsing.sourceforge.n­et.

-- Paul McGuire


Version 1.3.1 - June 12, 2005
-----------------------------
- Added markInputline() method to ParseException, to display the input
text line location of the parsing exception. (Thanks, Stefan
Behnel!)

- Added setDefaultKeywordChars(), so that Keyword definitions using a
custom keyword character set do not all need to add the keywordChars
constructor argument (similar to setDefaultWhitespaceChars()).
(suggested by rzhanka on the SourceForge pyparsing forum.)

- Simplified passing debug actions to setDebugAction(). You can now
pass 'None' for a debug action if you want to take the default
debug behavior. To suppress a particular debug action, you can pass
the pyparsing method nullDebugAction.

- Refactored parse exception classes, moved all behavior to
ParseBaseException, and the former ParseException is now a subclass
of ParseBaseException. Added a second subclass, ParseFatalException,
as a subclass of ParseBaseException. User-defined parse actions can
raise ParseFatalException if a data inconsistency is detected (such
as a begin-tag/end-tag mismatch), and this will stop all parsing
immediately. (Inspired by e-mail thread with Michele Petrazzo -
thanks, Michelle!)

- Added helper methods makeXMLTags and makeHTMLTags, that simplify the
definition of XML or HTML tag parse expressions for a given tagname.

Both functions return a pair of parse expressions, one for the
opening tag (that is, '<tagname>') and one for the closing tag
('</tagname>'). The opening tagame also recognizes any attribute
definitions that have been included in the opening tag, as well as
an empty tag (one with a trailing '/', as in '<BODY/>' which is
equivalent to '<BODY></BODY>').

makeXMLTags uses stricter XML syntax for attributes, requiring that
they be enclosed in double quote characters - makeHTMLTags is more
lenient, and accepts single-quoted strings or any contiguous string
of characters up to the next whitespace character or '>' character.
Attributes can be retrieved as dictionary or attribute values of
the returned results from the opening tag.

- Added example SimpleCalc.py, a refinement on fourFn.py that adds
an interactive session and support for variables. (Thanks, Steven
Siew!)

- Added performance improvement, up to 20% reduction! (Found while
working with Wolfgang Borgert on performance tuning of his TTCN3
parser.)

- And another performance improvement, up to 25%, when using
scanString! (Found while working with Henrik Westlund on his C
header file scanner.)

- Updated UML diagrams to reflect latest class/method changes.
 
C

Christopher Subich

Paul said:
(sorry if this is a double-post - I tried posting this last night but I
think GoogleGroups ate it)

Pyparsing is a pure-Python class library for quickly and easily
constructing recursive-descent parsers. Pyparsing takes a
"building-block" approach to parser construction, as opposed to code
generation methods (such as lex/yacc) or pattern definition strings
(such as regular expressions).

Funnily enough, I've been thinking about something exactly like this.
I've realized that my desired scripting language for the mud client I'm
writing is very much a CFG, so simple regexes aren't going to cut it.

The biggest issue for me is command syntax -- commands can have one of a
number of parameter formats (number and type of parameters can vary).
With a special command-marker at the beginning of the expression, I know
unambiguously what is a command and what is not, but I'd need to look up
in a dictionary (indexed by command name) the types. Is the pyparsing
tokenizer flexible enough to let me do this sort of thing easily?
 
P

Peter Hansen

Christopher said:
Is the pyparsing
tokenizer flexible enough to let me do this sort of thing easily?

I can't say that for sure, but I can say that it is certainly easy
enough to try it out (and well enough documented) that downloading it,
installing it, and doing a quick proof-of-concept experiment would
probably take less time than waiting for a reply to that question. ;-)

-Peter
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,982
Messages
2,570,190
Members
46,740
Latest member
AdolphBig6

Latest Threads

Top