On 27 Feb 2013, at 11:00, David Beazley <d...@dabeaz.com> wrote: >> >> From: Eli Bendersky <eli...@gmail.com> >> >> I'll be the first one to admit that pycparser is almost certainly not >> generally useful enough to be exposed in the stdlib. So just using it as an >> implementation detail is absolutely fine. PLY is a more interesting >> question, however, since PLY is somewhat more generally useful. That said, >> I see all this as implementation details that shouldn't distract us from >> the main point of whether cffi should be added. >> > > Regarding the inclusion of PLY or some subcomponent of it in the standard > library, it's not an entirely crazy idea in my opinion.
+1 PLY is capable and well tried-and-tested. We used it in Resolver One to implement a pretty large grammar and it is (in my opinion) best of breed in the Python parser generator world. Being stable and widely used, with an "available maintainer", makes it an ideal candidate for standard library inclusion. Michael > LALR(1) parsers have been around for a long time, are generally known to > anyone who's used yacc/bison, and would be useful outside the context of cffi > or pycparser. PLY has also been around for about 12 years and is what I > would call stable. It gets an update about every year or two, but that's > about it. PLY is also relatively small--just two files and about 4300 lines > of code (much of which could probably be scaled down a bit). > > The only downside to including PLY might be the fact that there are very few > people walking around who've actually had to *implement* an LALR(1) parser > generator. Some of the code for that is extremely hairy and mathematical. > At this time, I don't think there are any bugs in it, but it's not the sort > of thing that one wants to wander into casually. Also, there are some > horrible hacks in PLY that I'd really like to get rid of, but am currently > stuck with due to backwards compatibility issues. > > Alex Gaynor has been working on a PLY variant (RPLY) geared at RPython and > which has a slightly different programming interface. I'd say if we were > to go down this route, he and I should work together to put together some > kind of more general "parsing.lalr" package (or similar) that cleans it up > and makes it more suitable as a library for building different kinds of > parsing tools on top of. > > Cheers, > Dave > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
