PEP 617: Add section on rejected alternatives (#1359)

pep-0617.rst

@@ -755,6 +755,31 @@ faster but uses slightly (about 10%) more memory. We believe this is
 acceptable. (Also, there are probably some more tweaks we can make to
 reduce memory usage.)
 
+=====================
+Rejected Alternatives
+=====================
+
+We did not seriously consider alternative ways to implement the new
+parser, but here's a brief discussion of LALR(1).
+
+Thirty years ago the first author decided to go his own way with
+Python's parser rather than using LALR(1), which was the industry
+standard at the time (e.g. Bison and Yacc).  The reasons were
+primarily emotional (gut feelings, intuition), based on past experience
+using Yacc in other projects, where grammar development took more
+effort than anticipated (in part due to shift-reduce conflicts).  A
+specific criticism of Bison and Yacc that still holds is that their
+meta-grammar (the notation used to feed the grammar into the parser
+generator) does not support EBNF conveniences like
+``[optional_clause]`` or ``(repeated_clause)*``.  Using a custom
+parser generator, a syntax tree matching the structure of the grammar
+could be generated automatically, and with EBNF that tree could match
+the "human-friendly" structure of the grammar.
+
+Other variants of LR were not considered, nor was LL (e.g. ANTLR).
+PEG was selected because it was easy to understand given a basic
+understanding of recursive-descent parsing.
+
 ==========
 References
 ==========