Python parser generators

[anton muhin]

Hello, everybody!

Can someone give an overview of existing Python parser generators?

I played with TPG and like it a lot. However, I'd like to know more
about alternatives. Google shows several options: PyLR, DParser, etc.

I'm not intrested in ultra-speed: TPG although claims to be not
lighting-quick seems quick enough for my needs, I'm rather looking for
convinience and expressivness.

TIA,
anton.

[François Pinard]

Re: Python parser generators

[anton muhin]
[color=blue]
> Can someone give an overview of existing Python parser generators?
> [...] I'm rather looking for convenience and expressiveness.[/color]

Hello, Anton.

I looked at a few, but did not look at them all, and finally settled for
SPARK for production. (I do not fully understand why a few generators
which were written after SPARK did not at least recycle its elegance.)

SPARK is not blazing fast, but is not inordinately slow either, _given_
you write reasonable grammars. By "reasonable ", I do not mean small,
we indeed use some rather big ones here. But I mean grammars which are
rather left-to-right-ly, and for which big inputs could be chumped into
smaller syntactical units at lexical time. In that way, each of the
repeated call to a SPARK parser in an application is not given the whole
input -- we found out that this is worth, and usually easy to do. Our
parsers are easy to maintain and very dependable. We are happy with it.

--
François Pinard http://www.iro.umontreal.ca/~pinard

[Dave Kuhlman]

Re: Python parser generators

François Pinard wrote:
[color=blue]
> [anton muhin]
>[color=green]
>> Can someone give an overview of existing Python parser
>> generators?
>> [...] I'm rather looking for convenience and expressiveness.[/color]
>
> Hello, Anton.
>
> I looked at a few, but did not look at them all, and finally
> settled for
> SPARK for production. (I do not fully understand why a few
> generators which were written after SPARK did not at least recycle
> its elegance.)
>
> SPARK is not blazing fast, but is not inordinately slow either,
> _given_
> you write reasonable grammars. By "reasonable ", I do not mean
> small,
> we indeed use some rather big ones here. But I mean grammars
> which are rather left-to-right-ly, and for which big inputs could
> be chumped into
> smaller syntactical units at lexical time. In that way, each of
> the repeated call to a SPARK parser in an application is not given
> the whole
> input -- we found out that this is worth, and usually easy to do.
> Our
> parsers are easy to maintain and very dependable. We are happy
> with it.
>[/color]

And, here is a link to a comparison document:

http://www.python.org/sigs/parser-sig/towards-standard.html

The above article does not mention PLY. I used PLY to write (most
of) a parser for the RELAX NG compact syntax. PLY worked well for
me. PLY is available at:

http://systems.cs.uchicago.edu/ply/.

The parser for the RELAX NG compact syntax might serve as a
reasonable example of how to use PLY. It is available at:

http://www.rexx.com/~dkuhlman/relaxngcompact.html

And, I've written a bit of documentation on how to use Python parser
generators, which is at:

http://www.rexx.com/~dkuhlman/python...ython_201.html.

Dave

--

http://www.rexx.com/~dkuhlman

dkuhlman@rexx.c om