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

Brett Cannon brett at python.org
Sun Jul 14 15:13:13 CEST 2013


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130714/6cf557e5/attachment.html>


More information about the Python-Dev mailing list