471,305 Members | 1,105 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,305 software developers and data experts.

Python parser generators

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.

Jul 18 '05 #1
2 1367
[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.

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

Jul 18 '05 #2
François Pinard wrote:
[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-si...-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
dk******@rexx.com
Jul 18 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

699 posts views Thread by mike420 | last post: by
3 posts views Thread by Simon Foster | last post: by
19 posts views Thread by Leif K-Brooks | last post: by
4 posts views Thread by Michael | last post: by
13 posts views Thread by Wiseman | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.