Python parser generators

A

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

=?iso-8859-1?Q?Fran=E7ois?= Pinard

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

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

Dave Kuhlman

François Pinard said:
[anton muhin]
Can someone give an overview of existing Python parser
generators?
[...] I'm rather looking for convenience and expressiveness.

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.

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_201/python_201.html.

Dave
 

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,769
Messages
2,569,580
Members
45,055
Latest member
SlimSparkKetoACVReview

Latest Threads

Top