On Sun, Jul 14, 2013 at 2:54 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 13 July 2013 23:26, David Beazley <d...@dabeaz.com> wrote: > >> I'm in favor of PLY going into stdlib with the caveat that there are some >> things about it that should probably be cleaned up and modernized. For >> instance, the method by which it writes the cached parsing tables needs to >> be cleaned up. I still think putting the LALR(1) generator code into a >> common library usable by both PLY/RPLY would be a useful thing to do. That >> code is really hairy and non-trivial to understand without something like >> the Dragon book nearby (and even then it's not easy). >> >> So, if I were to make any kind of proposal, I would say, make a standard >> library module for just the LALR(1) generator code. If the PLY interface >> is needed to add pycparser or cffi to the standard library, that can be >> added too, but as a separate module that uses the more general LALR(1) >> library. >> > > lrparsing is a more recent entry in the LR parsing stakes: > https://pypi.python.org/pypi/lrparsing (although, as Russell put it in > his PyCon AU lightning talk, if PLY had shown up ranked higher than 506 in > his PyPI search for "parser", he probably would have just used that: > http://pyvideo.org/video/2222/sunday-lightning-talks at about 2:15) > > (I plan to bug Russell about putting that up on one of the DVCS hosting > sites next time I see him at BrisPy - for the moment, the source is > available through the tarball/sdist) > It seems a bit new compared to PLY's 15 years of existence to be considered in the running. Plus Russell would need to change the license from GPL.
_______________________________________________ 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