On 15 July 2013 07:01, Raymond Hettinger wrote:
> I would love to have PLY in the standard library.
> It would open up a whole new world to some users
> and be the basis for tool generation for others.
>
+1. Parser generators are useful tools - parsers are right on the boundary
of "easy enough to
On 15 July 2013 16:01, Raymond Hettinger wrote:
>
> On Jul 14, 2013, at 6:32 AM, David Beazley wrote:
>
> 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.
>
>
> I would love to have PLY in t
On Jul 14, 2013, at 6:32 AM, David Beazley wrote:
> 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.
I would love to have PLY in the standard library.
It would open up a whole new world
On Jul 14, 2013, at 8:13 AM, Brett Cannon wrote:
>
>
>
> On Sun, Jul 14, 2013 at 2:54 AM, Nick Coghlan wrote:
> On 13 July 2013 23:26, David Beazley 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 mod
On Sun, Jul 14, 2013 at 2:54 AM, Nick Coghlan wrote:
> On 13 July 2013 23:26, David Beazley 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
On 13 July 2013 23:26, David Beazley 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
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 co
On Sat, Jul 13, 2013 at 4:24 AM, Michael Foord wrote:
>
> On 13 Jul 2013, at 07:41, Terry Reedy wrote:
>
> > On 7/13/2013 12:10 AM, Eric Snow wrote:
> >>
> >> On Feb 27, 2013 4:31 AM, "Michael Foord" >
> >> > +1 PLY is capable and well tried-and-tested. We used it in Resolver
> >> One to impleme
David Beasley; see earlier in this same thread:
http://mail.python.org/pipermail/python-dev/2013-February/thread.html#124389
On Fri, Jul 12, 2013 at 9:41 PM, Terry Reedy wrote:
> On 7/13/2013 12:10 AM, Eric Snow wrote:
>
>>
>> On Feb 27, 2013 4:31 AM, "Michael Foord" >
>
> > +1 PLY is capab
On 7/13/2013 12:10 AM, Eric Snow wrote:
On Feb 27, 2013 4:31 AM, "Michael Foord"
> +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
On Feb 27, 2013 4:31 AM, "Michael Foord" wrote:
>
>
> On 27 Feb 2013, at 11:00, David Beazley wrote:
>
> >>
> >> From: Eli Bendersky
> >>
> >> 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
>
On 27 Feb 2013, at 11:00, David Beazley wrote:
>>
>> From: Eli Bendersky
>>
>> 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 intere
12 matches
Mail list logo
