On 7/24/2019 9:15 PM, Nam Nguyen wrote:
Back to my original requests to the list: 1) Whether we want to have a
(possibly private) parsing library in the stdlib, and 2) What features
it should have. I have proposed that 1) yes, such a library would be
useful, and 2) several requirements that such a library should fulfill.
Are they acceptable? Apparently not. As you first requested for debug
trace, Barry wanted better performance, and Chris asked for proof such
library would help. How about the other points I suggested? Do we need a
full-blown universal parser? Is LL(1) enough, or do we need k /
unlimited lookaheads? How about context sensitive grammars? What
performance budget can we spend on this vs the status quo? Do we even
care if the parser is small, or that it comes from generated code? Et
cetera... There are still plenty of open questions.
I would think deciding on LL(1), or a specific k lookahead, or any other
parser feature would depend on which problems you're trying to solve.
I think you're looking at this backwards. You seem to be saying "here's
a parser, now solve problems in the stdlib with it". For something in
the stdlib, I think it has to be "here are the problems to be solved,
now I'll design a parser to solve them".
To take but one example: what if it turns out that a URL can't be parsed
with a LL(1) parser, and you need more horsepower? Don't you think you'd
need to know that in advance of proposing a LL(1) parser for the stdlib?
And herein lies an issue: you can't design a parser that solves every
issue that the stdlib will ever have. At best you can only solve the
existing problems. But if you do that, what do you do if we want to add
something new to the stdlib that your parser doesn't have enough power
to parse?
To try and be more concretely helpful: at the very least, I think you
should propose a specific set of things in the existing stdlib that
would benefit from a parser generator, instead of the existing ad hoc
parsers being used. Bonus points for showing how the code is simplified
and/or made more secure by using a parser generator.
Eric
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/FHRLTEGVUO2DXJZN4KYY2HNEN7KJ65Y6/
Code of Conduct: http://python.org/psf/codeofconduct/
