pyparsing-users — User notes and help on the pyparsing module

Re: [Pyparsing] jsonParser.py patch

[thomas_h <th...@go...>]

Done. It's at http://pyparsing.pastebin.com/m2c33d08d, if that is of
help. Thanks for the hints.

Thomas

On Tue, Apr 22, 2008 at 6:40 PM, Paul McGuire <pt...@au...> wrote:
> Your attachment was stripped somewhere along the way.  Could you please
>  paste it to a http://pyparsing.pastebin.com/?
>
>  Thanks,
>  -- Paul
>
>
>
>  -----Original Message-----
>  From: pyp...@li...
>  [mailto:pyp...@li...] On Behalf Of thomas_h
>  Sent: Tuesday, April 22, 2008 10:35 AM
>  To: pyp...@li...
>  Subject: [Pyparsing] jsonParser.py patch
>
>  Hi all,
>
>  I've changed the jsonParser.py example from the distro to accommodate
>  top-level arrays (as of RFC4627, http://tools.ietf.org/html/rfc4627).
>  Please find the patch attached.
>
>  Cheers,
>  Thomas
>
>

Re: [Pyparsing] jsonParser.py patch

[Paul M. <pt...@au...>]

Your attachment was stripped somewhere along the way.  Could you please
paste it to a http://pyparsing.pastebin.com/?

Thanks,
-- Paul 

-----Original Message-----
From: pyp...@li...
[mailto:pyp...@li...] On Behalf Of thomas_h
Sent: Tuesday, April 22, 2008 10:35 AM
To: pyp...@li...
Subject: [Pyparsing] jsonParser.py patch

Hi all,

I've changed the jsonParser.py example from the distro to accommodate
top-level arrays (as of RFC4627, http://tools.ietf.org/html/rfc4627).
Please find the patch attached.

Cheers,
Thomas

[Pyparsing] jsonParser.py patch

[thomas_h <th...@go...>]

Hi all,

I've changed the jsonParser.py example from the distro to accommodate
top-level arrays (as of RFC4627, http://tools.ietf.org/html/rfc4627).
Please find the patch attached.

Cheers,
Thomas

[Pyparsing] Quick doc hint

[thomas_h <th...@go...>]

Hi list,

a quick hint regarding the docs that come with pyparsing:
I was always struggling a bit since epydoc doesn't generate 'data'
entries, so I was looking in vain in the generated doc for things like
'alphanums', 'cppStyleComment' and the likes. They never show up,
although they're part of pyparsing's interface none-the-less.
Looking for a fast solution I found that Python's built-in pydoc is
less restrictive. Do a

  pydoc -w ./pyparsing.py

in the directory where the module resides, and you'll get a (yes, less
sexy) HTML page generated that contains all the 'data' entries.

HTH,
Thomas

Re: [Pyparsing] Get Better Error Messages - Prevent Backtracking

[Paul M. <pt...@au...>]

Eike -

Wow! SIML is really quite an expressive language.  I've added a link to the
"Who's Using Pyparsing" page of the wiki to your project.

pyparsing already has setErrorAction, although it is called setFailAction.
Here is the docstring:

        """Define action to perform if parsing fails at this expression. 
           Fail acton fn is a callable function that takes the arguments 
           fn(s,loc,expr,err) where:
            - s = string being parsed
            - loc = location where expression match was attempted and failed
            - expr = the parse expression that failed
            - err = the exception thrown
           The function returns no value.  It may throw ParseFatalException
           if it is desired to stop parsing immediately."""


If you are generating code, you might look into using Python's import hooks.
Here is an example where I use pyparsing to parse state machine definitions
in a file with the extension .pystate, where the states are defined with a
state machine like:

TrafficLight = {
    Red -> Green;
    Green -> Yellow;
    Yellow -> Red;
    }

Here is the full example, with links to the code:
http://www.geocities.com/ptmcg/python/index.html#stateMachine
(I will be updating this soon to use an indentation-based parser for state
machines, so I can get rid of those {}'s and ;'s!)

-- Paul

Re: [Pyparsing] Get Better Error Messages - Prevent Backtracking

[Eike W. <eik...@gm...>]

I'm really glad that my proposal seems to be usefull for others. I was 
quite astonished how easy it was to implement the idea. So Pyparsing 
is not only an easy to use parsing library, it is also easy to write 
extensions for it. 

On Sunday 20 April 2008 16:58, you wrote:
> I am sorting out what to release in the next version of pyparsing. 
> I will definitely include ErrStop or something similar.  I would
> also like to get an idea of any patterns of usage, to see if there

I use ErrStop in my toy language, which is a crude special purpose 
language. 
http://freeode.berlios.de/
The parser is a pretty long snippet from an even longer file:
http://pastebin.com/f70bba102

> is a natural place to automatically include this feature, in an And
> say.  Or perhaps just incorporate this logic into the And class's

A cooperative And, that treats ErrStop specially, would be great! Then 
one could write:
dataDef2 = Group(Keyword('data') + ErrStop()
                 + attrNameList + ':' + identifier + ';')

> parseImpl method.  Or make raiseErrorStop an attribute of And (or
> maybe just of ParserElement), so that any class can report its
> error location.

An other general method to deal with errors would be the introduction 
of error actions. ParserElement would get a function:
	setErrorAction( callableObject )
The error actions would maybe have the signature:
	errAction( str, loc, error )
 
In the error action the error (ParseException) could be examined, and 
a fatal exception could be raised if desired.

>
> I'm also looking at something like lastParseLoc.  Ideally I'd like
> lastParseLoc to be an attribute of a ParseStatus object that is
> passed through the grammar - this would be a natural home for
> lastParseLoc, as well as things like global debugging flags,
> whitespace character sets, packrat caches, etc.  But I think I
> would also want to pass this object to parse actions, and this
> would break the interface to all existing parse actions.

To keep compatibility you could go the Microsoft way and introduce the 
function:
	setParseActionEx( ... )
Or to let old code run with only minimal changes:
	setParseActionOld( ... )
:-)
>
> :(  So for now, it will probably have to be a class attribute, the
> : same way
>
> that the packrat cache is handled.
>
> So these changes could get pretty drastic.  I'll keep them to a
> minimum for compatability with 1.4.x, maybe bump the minor version
> to 1.5, and save the really drastic changes for 2.0 someday.
>
> -- Paul

Kind regards,
Eike. 

Re: [Pyparsing] Get Better Error Messages - Prevent Backtracking

[Paul M. <pt...@au...>]

I am sorting out what to release in the next version of pyparsing.  I will
definitely include ErrStop or something similar.  I would also like to get
an idea of any patterns of usage, to see if there is a natural place to
automatically include this feature, in an And say.  Or perhaps just
incorporate this logic into the And class's parseImpl method.  Or make
raiseErrorStop an attribute of And (or maybe just of ParserElement), so that
any class can report its error location.

I'm also looking at something like lastParseLoc.  Ideally I'd like
lastParseLoc to be an attribute of a ParseStatus object that is passed
through the grammar - this would be a natural home for lastParseLoc, as well
as things like global debugging flags, whitespace character sets, packrat
caches, etc.  But I think I would also want to pass this object to parse
actions, and this would break the interface to all existing parse actions.
:(  So for now, it will probably have to be a class attribute, the same way
that the packrat cache is handled.

So these changes could get pretty drastic.  I'll keep them to a minimum for
compatability with 1.4.x, maybe bump the minor version to 1.5, and save the
really drastic changes for 2.0 someday.

-- Paul


-----Original Message-----
From: pyp...@li...
[mailto:pyp...@li...] On Behalf Of W.
Martin Borgert
Sent: Sunday, April 20, 2008 3:50 AM
To: Eike Welk
Cc: pyp...@li...
Subject: Re: [Pyparsing] Get Better Error Messages - Prevent Backtracking

On Mon, Apr 14, 2008 at 01:16:35AM +0200, Eike Welk wrote:
> I want to propose an other way, how to get better error messages: 
> Prevent backtracking at certain points in the grammar.

I like your approach and will probably use it in one of my two pyparsing
projects. Unfortunately, my other projects has about 600 BNF productions,
some of them non-trivial. Adding ErrStop to at least 100 or 200 of them
would clutter my code a lot and I'm yet sure it even would give the desired
result. For that grammar I still hope for inclusion of LastParseLoc or sth.
similar in pyparsing :~)

Thanks Eike, Gre7g, and Paul!


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss
this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javao
ne
_______________________________________________
Pyparsing-users mailing list
Pyp...@li...
https://lists.sourceforge.net/lists/listinfo/pyparsing-users

Re: [Pyparsing] Get Better Error Messages - Prevent Backtracking

[W. M. B. <de...@de...>]

On Mon, Apr 14, 2008 at 01:16:35AM +0200, Eike Welk wrote:
> I want to propose an other way, how to get better error messages: 
> Prevent backtracking at certain points in the grammar.

I like your approach and will probably use it in one of my two
pyparsing projects. Unfortunately, my other projects has about
600 BNF productions, some of them non-trivial. Adding ErrStop to
at least 100 or 200 of them would clutter my code a lot and I'm
yet sure it even would give the desired result. For that grammar
I still hope for inclusion of LastParseLoc or sth. similar in
pyparsing :~)

Thanks Eike, Gre7g, and Paul!

[Pyparsing] Get Better Error Messages - Prevent Backtracking

[Ken K. <ksk...@gm...>]

Hi.. I'm a new pyparsing user, and I just wanted to comment on Eike
Welk's recent proposal [1] to improve error messages by stopping
backtracking at defined points using a "ErrStop" ParserElement.

It's awesome.  Totally flipping awesome.  I'd beat my head against the
wall for a couple of hours before I stumbled on it & was instantly
relieved.

I've posted a diff of the simpleSQL.py example to the pastebin [2]
that shows a use of ErrStop on a statement that was previously happily
accepted ("select * from table1 where a b" -- note the missing
operator).  The diff assumes that ErrStop has been added to pyparsing.

Thanks Eike for the solution, and to Paul for the excellent package!
-ken

PS: Sorry for creating a new thread.. I don't know how to continue the
old one when I wasn't a list member until just now.

PSS: Since the docs & examples aren't in the svn repos, the diff is
against what was in the 1.4.11 tarball.

[1]
http://sourceforge.net/mailarchive/message.php?msg_name=200804140116.37166.eike.welk%40gmx.net

[2]
http://pastebin.com/f25124b32

[Pyparsing] The code is here (2nd try)

[Eike W. <eik...@gm...>]

The code is now available here:

http://pastebin.com/f762576c5


The Berlios FTP server seems to be somehow unreliable. 

Re: [Pyparsing] Example program here

[Ralph C. <ra...@in...>]

Hi Erik,

> It seems to be impossible to attach files to mails on this list. 
> Therefore I have put the example program on an FTP server. Here is the 
> directory:
> 
>     ftp://ftp.berlios.de/pub/freeode/
> 
> The file name is:
>      test_parse_stop.py

You `stop backtracking' method of error handing seems good, however, I'm
having trouble getting to the above example.

    $ lftp -c 'get ftp://ftp.berlios.de/pub/freeode/test_parse_stop.py'
    get: Login failed: 530 Sorry, you may not connect more then 2 times.
    $ 

wget(1) also fails, but with less of a diagnostic.

What about putting it on http://pastebin.com/ saying it should remain
`forever'.

Cheers,


Ralph.

[Pyparsing] Example program here

[Eike W. <eik...@gm...>]

It seems to be impossible to attach files to mails on this list. 
Therefore I have put the example program on an FTP server. Here is the 
directory:

    ftp://ftp.berlios.de/pub/freeode/

The file name is:
     test_parse_stop.py

[Pyparsing] Get Better Error Messages - Prevent Backtracking

[Eike W. <eik...@gm...>]

I want to propose an other way, how to get better error messages: 
Prevent backtracking at certain points in the grammar. I have 
attached a simple example implementation that works with Pyparsing 
1.4.5.

Often it is clear that, when a certain parser fails, there is surely 
an error in the input. Backtracking in this situation is bad, because 
information about the location and the cause of the error might be 
lost. A common situation is after a keyword.

Imagine a programming language, where you define variables like this:
    data a, b, c: Real;

After the 'data' keyword there must be a list of variable names, a ':' 
character, the name of a type and a ';' character. If this pattern 
does not appear after the 'data' keyword there is an error in the 
program.  

(See lines 46, 47 in the example program.)
A usual parser for this statement would look like this:
    dataDef1 = Group(Keyword('data') 
                     + attrNameList + ':' + identifier + ';')

I propose the 'ErrStop' class, an additional 'ParserElement', that 
stops parsing when a parser given to it fails. It is used like this:
    dataDef2 = Group(Keyword('data') 
                     + ErrStop(attrNameList + ':' + identifier + ';'))                       

In the example program the 'data' statement is combined with two 
additional statements, 'foo1;' and 'foo2;' to form a programming 
language. The program output shows that using the 'ErrStop' class 
really preserves more information about the error (missing comma 
after position 15). Additionally the parse result of a successful run 
is not altered.


The program output:
Test regular parser:
[['foo1', ';'], ['data', 
['a', ',', 'a1', ',', 'b'], ':', 'Real', ';'], ['foo1', ';']]
Expected end of text (at char 6), (line:1, col:7)

Test parser with backtracking stop:
[['foo1', ';'], ['data', 
['a', ',', 'a1', ',', 'b'], ':', 'Real', ';'], ['foo1', ';']]
Expected ":" (at char 17), (line:1, col:18)

Re: [Pyparsing] better parse error reporting

[W. M. B. <de...@de...>]

On Wed, Apr 09, 2008 at 01:55:02PM -0500, Paul McGuire wrote:
> Thanks for the running thread on this "parse error capturing" patch.  I
> confess I've not yet had time this week to read it or fully assess it.  I've
> tried for a long time to get more accurate error locations in pyparsing.

Paul. Gre7g,

how do you feel about applying Gre7gs patch to pyparsing? While
it is not the ultimate solution, I think it makes a huge
immediate benefit for the users of pyparsing. It is "low-hanging
fruit", because the patch is already there, consists only of few
lines of code, and I tested it already successfully.

Re: [Pyparsing] better parse error reporting

[Paul M. <pt...@au...>]

Gre7g and Martin -

Thanks for the running thread on this "parse error capturing" patch.  I
confess I've not yet had time this week to read it or fully assess it.  I've
tried for a long time to get more accurate error locations in pyparsing.

The biggest problem I've had is in constructions like:

expr1 = OneOrMore( expr2 ) + expr3

and the input text contains:

valid_expr2 invalid_expr2 valid_expr2 valid_expr3

OneOrMore( expr2 ) succeeds after parsing the first valid_expr2, and moves
forward to try to parse an expr3.  Positioned at invalid_expr2, the parse of
expr3 fails, and you get an exception like "expected expr3 at (locn of
invalid_expr2)".

Or what is more likely occuring in many of these grammars is something like
this:

expr1 = OneOrMore( expr2 + expr3 + expr4 + expr5 + expr6 + expr7 + expr8 +
expr9 )

and the input text contains:

valid_expr2 ... valid_expr8 invalid_expr9

and the error says "expected expr1 at (locn of valid_expr2)" and you get
this puzzled "huh?" look on your face.

There is some code in pyparsing that tries to find the furthest successful
match, but the piecework nature the grammar (each object does its own
parsing in more or less isolation) means that I'm limited into how much
state I can pass up the chain, and in the case of a partially successful
OneOrMore(expr1) parse, I can't pass *anything* up.  The only alternative at
the moment is a global "here is the furthest I've gotten so far" variable,
which I suspect is the mechanism behind Gre7g's patch.

When I get some time, it might be worth revisiting pyparsing's design to see
if I can pass some form of state object from element to element, so that a
more suitable parse error location could be captured in it.

-- Paul

Re: [Pyparsing] better parse error reporting

[Gre7g L. <haf...@ya...>]

--- "W. Martin Borgert" <de...@de...> wrote:

> This patch is really helpful, many thanks!

No problemo.

> First, the performance penalty is very low, about 1%
> for me.
> 
> Second, the position of the error is now located
> much more
> accurate. Not 100% exact in my tests, but I can live
> with that.

Yeah this code locates the END of the last thing
parsed and ideally you'd like the BEGINNING of the
next thing.  There's probably somewhere else you could
stick the test, but I'm not sure where that would be.
Perhaps Paul could suggest a better place to move the
comparison code?

In my code, I just start with this location and then
skip over white space and comments and then reparse
the next "word" I can find. That way I can report what
I did not expect to encounter and where it was. 
Regardless, I would recommend doing that in your own
code anyhow, since it wouldn't make much sense to add
to pyparsing.py.

Gre7g

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Pyparsing] Using pyparsing to implement a matching engine for a regexp-like matching language?

[Paul M. <pt...@au...>]

Andrew -

Welcome to Pyparsing!  This is a very interesting application.

There are two examples in the pyparsing wiki that may help you in your work:
an EBNF parser and generator - parses EBNF and generates a pyparsing grammar
that implements that BNF
(http://pyparsing.wikispaces.com/space/showimage/ebnf.py and
http://pyparsing.wikispaces.com/space/showimage/ebnftest.py)
a regex inverter - parses a regex (restricted forms only) and returns a
generator that generates all input strings that would match that regex
(http://pyparsing-public.wikispaces.com/space/showimage/invRegex.py)

Unfortunately, I'd say these are both fairly advanced examples, and maybe a
bit overwhelming to a new pyparsing user.  Please work through some of the
simpler examples (marked with a "Start" icon) and then take a look at these
others.  

The basic "engine" or structure of a pyparsing program is:
- compose the parsing expressions
- call parseString
- process the returned ParseResults object (can be thought of like a list,
but advanced usages will return nested lists, and also dict-style results,
with matched tokens retrievable by name)

Here is the basic "Hello, World!" (or any greeting of the form "<word> ,
<word> <punctuation>") parser:

from pyparsing import Word, alphas, oneOf
# compose the parsing expression, using pyparsing classes and builtins
greet = Word(alphas) + "," + Word(alphas) + oneOf("! . ?")

# parse the input string
greetingTokens = greet.parseString("Howdy, Pardner!")

# process the returned results
for i,token in enumerate(greetingTokens):
    print i,token

Prints:
0 Howdy
1 ,
2 Pardner
3 !

I'd also recommend following some of the documentation links for more
detailed examples and discussions.

I have considered converting pyparsing to a streaming-type (or push) parser,
but as it turns out, this would be a radical redesign, maybe in version 2
someday.  I don't know of any other modules to refer you to that might
support push parsing.

-- Paul

[Pyparsing] Using pyparsing to implement a matching engine for a regexp-like matching language?

[Andrew W. <and...@gm...>]

I am trying to write a matching engine for a matching language for a
filtering proxy compatible with that of The Proxomitron. The matching
language is basically an extended superset of shell-style globs, with
functionality comparable to regexps (see
http://www.proxomitron.info/45/help/Matching%20Rules.html).

I think that I can implement the parser for the match and replace
patterns themselves using pyparsing, but I am not exactly sure of how to
implement the "core" of the matching engine - the part that takes an
input string, finds a match, and extracts any parts specified in the
pattern.

I could almost use pyparsing as a matching engine as well, by
dynamically generating a parser from the pattern and parsing the data to
be filtered with it, but pyparsing appears to be a pull parser (one that
takes all its input at once), as opposed to a push parser (which can be
fed multiple chunks of input). Also, non-matching input might cause
parse errors.

A matching engine for a filtering proxy has to be able to handle partial
input and "hold" data until enough is received to determine whether
there is a match (or else the entire document would have to be held
until the end is reached, filtered, and then sent all at once to the
remote client, and that would make it appear much less responsive and
possibly break some applications).

Is there a way to use pyparsing as a push parser, or can anyone
recommend any other Python libraries that would be suitable for my
purposes?
I don't want to reinvent the wheel unless no suitable library exists.

[Pyparsing] Using pyparsing to implement a matching engine for a regexp-like matching language?

[Andrew W. <and...@gm...>]

I am trying to write a matching engine for a matching language for a 
filtering proxy compatible with that of The Proxomitron. The matching 
language is basically an extended superset of shell-style globs, with 
functionality comparable to regexps (see 
http://www.proxomitron.info/45/help/Matching%20Rules.html).

I think that I can implement the parser for the match and replace
patterns themselves using pyparsing, but I am not exactly sure of how to
implement the "core" of the matching engine - the part that takes an
input string, finds a match, and extracts any parts specified in the
pattern.

I could almost use pyparsing as a matching engine as well, by
dynamically generating a parser from the pattern and parsing the data to
be filtered with it, but pyparsing appears to be a pull parser (one that
takes all its input at once), as opposed to a push parser (which can be
fed multiple chunks of input). Also, non-matching input might cause
parse errors.

A matching engine for a filtering proxy has to be able to handle partial
input and "hold" data until enough is received to determine whether
there is a match (or else the entire document would have to be held
until the end is reached, filtered, and then sent all at once to the
remote client, and that would make it appear much less responsive and
possibly break some applications).

Is there a way to use pyparsing as a push parser, or can anyone
recommend any other Python libraries that would be suitable for my 
purposes? I don't want to reinvent the wheel unless no suitable library 
exists.

Re: [Pyparsing] better parse error reporting

[W. M. B. <de...@de...>]

On Tue, Apr 08, 2008 at 08:18:32PM -0500, Paul McGuire wrote:
> Pyparsing includes the line, lineno, and col builtins.  You can convert a
> location to the corresponding line of text by calling line(locn,string). 

Thanks for the hint! Because LastParseLoc might be slightly
inaccurate, line() might return an empty line following the
wrong input, but lineno() is helpful. E.g. in:

  string = open(filename).read()
  lineno = pyparsing.lineno(pyparsing.LastParseLoc, string)
  col = pyparsing.col(pyparsing.LastParseLoc, string)
  print >>sys.stderr, "%s:%d:%d: Parse Error!" % (filename, lineno, col)
  print >>sys.stderr, "\n".join(string.split("\n")[max(0, lineno - 3):lineno])

The split/join is prabably a bad idea, esp. for large input
files, though.

Re: [Pyparsing] better parse error reporting

[Paul M. <pt...@au...>]

Pyparsing includes the line, lineno, and col builtins.  You can convert a
location to the corresponding line of text by calling line(locn,string). 

-- Paul


-----Original Message-----
From: pyp...@li...
[mailto:pyp...@li...] On Behalf Of W.
Martin Borgert

Third, with the numeric position, one can calculate the line number in a
larger input file and print out the suspicious line(s). A convenience
function for this would be nice in pyparsing, but maybe this is too
application specific.

Re: [Pyparsing] better parse error reporting

[W. M. B. <de...@de...>]

On Tue, Apr 08, 2008 at 08:40:05AM -0700, Gre7g Luterman wrote:
> Okay, here's a hack to try. It's not real pretty and I
> haven't thoroughly tested it either, but it's a good
> starting point, at least.

This patch is really helpful, many thanks!

First, the performance penalty is very low, about 1% for me.

Second, the position of the error is now located much more
accurate. Not 100% exact in my tests, but I can live with that.

Third, with the numeric position, one can calculate the line
number in a larger input file and print out the suspicious
line(s). A convenience function for this would be nice in
pyparsing, but maybe this is too application specific.

> First, apply the following patch to pyparsing.py. Be
> careful. Your line numbers may vary a bit because I've
> added the ternary code discussed earlier which may not
> be in the current release just yet:

The patch is so small, that I applied it manually, not with the
patch tool. No problem.

That said, I suggest that this should be a standard feature of
pyparsing. Many users would welcome it, I'm sure.

Thanks again!

Re: [Pyparsing] better parse error reporting

[Gre7g L. <haf...@ya...>]

--- "W. Martin Borgert" <de...@de...> wrote:

> That would be cool! I think, this is something most
> pyparsing
> users would welcome. How valuable sane error
> reporting is, one
> notices, if it's missing, such as in LaTeX. Thanks
> for any help!

Okay, here's a hack to try. It's not real pretty and I
haven't thoroughly tested it either, but it's a good
starting point, at least.

First, apply the following patch to pyparsing.py. Be
careful. Your line numbers may vary a bit because I've
added the ternary code discussed earlier which may not
be in the current release just yet:

http://pastie.textmate.org/177251

Then you can test it out with this really stupid
parser script:

http://pastie.textmate.org/177253

As you can see, all I'm doing is recording how far the
parser made it (hopefully I'm doing this at the right
spot) and keeping that in a global variable that you
can access later.

It's a little Kludgey, but as Kludges go, it is pretty
minor.

HTH,
Gre7g

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Pyparsing] automatic naming of parse results?

[W. M. B. <de...@de...>]

On Sat, Apr 05, 2008 at 02:16:18AM -0500, Paul McGuire wrote:
> Results names are tricky, but useful.  Part of the nuisance of results names
> is the ".setResultsName" syntax, so that is why in 1.4.7 I added support for
> code like this:
>
>     a = pyparsing.Group(b + c)("a")
>
> That is, I made all ParserElements callable, and __call__ calls
> setResultsName.

I use this variant now. It's sufficient for me. Thanks a lot!

Re: [Pyparsing] better parse error reporting

[W. M. B. <de...@de...>]

On Fri, Apr 04, 2008 at 08:26:08AM -0700, Gre7g Luterman wrote:
> Oof. If you're looking at a huge grammar, then you
> might consider the "hacking pyparsing.py" route
> instead.
...
> Would you like me to take a crack at this hack?

That would be cool! I think, this is something most pyparsing
users would welcome. How valuable sane error reporting is, one
notices, if it's missing, such as in LaTeX. Thanks for any help!