On 7/1/2020 4:14 PM, Rob Cliffe via Python-Dev wrote:
I have an uneasy feeling about this PEP.
I can understand that.
AFAIK the usual procedure for adding a new feature to Python is:
An idea is raised and attracts some support.
Someone sufficiently motivated writes a PEP.
The PEP is thoroughly discussed.
Eventually a consensus (or at least an "agree to differ" stalemate)
is reached.
The PEP is accepted (if it is).
(Then and only then) Someone works on the implementation.
etc.
To the extent that this is true, a big reason is that many people do not
want to write code until they are somewhat sure it will be accepted.
But we can almost never be sure until we know what the code is, or will
be -- in detail.
'Show us some code' is common in discussion. Is the feature possible,
or are we wasting out time discussing it? Will it be fast enough? Will
the code be maintainable? Or too ugly to look at?
The same issue comes up on bpo issues. 'Please either give a really
detailed specification, or submit a PR.' 'Will it be accepted?' 'We
cannot tell until we see it.'
Sometimes, someone not a PEP or bpo issue author offers to contribute an
implementation to move discussion along to possible acceptance.
However, PEP 622 only seems to have been presented to the Python
community only *after* a well-developed (if not finalised)
implementation was built. A fait accompli.
I would be annoyed too if I thought it were true, but I don't. AFAIK,
the implementation on someone's private fork has not yet been presented
as a PR ready to be committed at the press of the green button.
And since the PEP has Guido's authority behind it, I think
it is likely that it will eventually be accepted pretty much as it was
originally written.
I suspect that Guido retired from the decision council in part so that
he could submit PEP level changes to it as an independent person not on
the council.
The new PEG parser was the first new PEP. I believe Guido was looking at
PEG parsers last summer, before last fall's council election. The
theoretical advantage was clear; the practical application to Python not
so much. He refrained from submitting a PEP until he had a couple of
collaborators to help produce an initial implementation that answered
the inevitable questions that would have made discussion without an
implementation moot. Is a PEG parser matching the current parser
possible?, fast enough?, compact enough?, and 'will there be the needed
follow through maintenance'?
It is common for a reasonably complicated context free grammar to be
ambiguous in the sense that a given sequence of tokens can be produced
by more than one sequence of applications of the production rules. But
we want machine parsing of code to a particular sequence to be
unambiguious, deterministic, and fast. An LL(1) parser uses and is
limited to one token lookahead and cannot unambiguously parse all
context-free languages. The PEG parser cuts the ambiguity knot by
ordering production rules and accepting the first match.
This is the same rule proposed for match statements and is similar to
the disambiguating rule for if statements in Python and many other
languages (but not all): first true condition wins. (Python also does
the same for expressions with side-effects with a left-to-right
evaluation rule.) Each condition is implicitly augmented with 'and none
of the previous conditions'. In ordered matching, each pattern has a
similar implicit condition.
Ordered evaluation at the expression level is not much of an issue for
human readers. I think making words keywords only in certain easily
read contexts, such as 'match' followed by <expression> followed by ':',
is also not much of an issue.
I suspect that some of the proposed match patterns require the new PEP
parser and that this has something to do with people's uneasiness.
Removing the LL(1) limitation lets us add grammar rules that we want,
but also allows for constructions that are unneeded* or hard for humans
to read.
*Prior to the match proposal, Guido reported on python-ideas that he had
developed a PEG grammar and resulting parser and compiler that allowed
for omitting parentheses in at least some calls with arguments. He
dropped the idea when the coredev reaction was neutral to negative.
--
Terry Jan Reedy
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/WCGSM2BA7PMI6DN3Q6MJOLR4EKV5SCI5/
Code of Conduct: http://python.org/psf/codeofconduct/
