[Python-Dev] PLY in stdlib (was cffi in stdlib)

David Beazley dave at dabeaz.com
Sun Jul 14 15:32:28 CEST 2013


On Jul 14, 2013, at 8:13 AM, Brett Cannon wrote:

> 
> 
> 
> On Sun, Jul 14, 2013 at 2:54 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 13 July 2013 23:26, David Beazley <dave at 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. 

I honestly don't have any particular thoughts about PLY vs. other parser generators and the merits of their inclusion (or not) in the standard library.   My impression has always been that the main interest in PLY was due to interest in seeing CFFI in the standard library.  I'd say my main desire on the PLY side is that if it does go into the standard library, perhaps I could make it slightly less of mysterious black box and clean up a few bits.

Cheers,
Dave

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130714/5a02e24f/attachment.html>


More information about the Python-Dev mailing list