Fold PEP 13 draft into PEP 3099.

pep-3099.txt

@@ -12,17 +12,47 @@ Created: 04-Apr-2006
 Abstract
 ========
 
-This PEP tries to list all BDFL pronouncements on Python 3000 that
-refer to changes that will not happen and new features that will not
-be introduced, sorted by topics, along with a short explanation or a
-reference to the relevant thread on the python-3000 mailing list.
+Some ideas are just bad.  While some thoughts on Python evolution are
+constructive, some go against the basic tenets of Python so
+egregiously that it would be like asking someone to run in a circle:
+it gets you nowhere, even for Python 3000, where extraordinary
+proposals are allowed.  This PEP tries to list all BDFL pronouncements
+on Python 3000 that refer to changes that will not happen and new
+features that will not be introduced, sorted by topics, along with
+a short explanation or a reference to the relevant thread on the
+python-3000 mailing list.
+
+If you think you should suggest any of the listed ideas it would be
+better to just step away from the computer, go outside, and enjoy
+yourself.  Being active outdoors by napping in a nice patch of grass
+is more productive than bringing up a beating-a-dead-horse idea and
+having people tell you how dead the idea is.  Consider yourself warned.
 
 
 Core language
 =============
 
+* ``self`` will not become implicit.
+
+   Having ``self`` be explicit is a *good thing*.  It makes the code
+   clear by removing ambiguity about how a variable resolves.  It also
+   makes the difference between functions and methods small.
+
+   Thread: "Draft proposal: Implicit self in Python 3.0"
+   http://mail.python.org/pipermail/python-dev/2006-January/059468.html
+
 * ``lambda`` will not be renamed.
 
+   At one point lambda was slated for removal in Python 3000.
+   Unfortunately no one was able to come up with a better way of
+   providing anonymous functions.  And so lambda is here to stay.
+
+   But it is here to stay as-is.  Adding support for statements is a
+   non-starter.  It would require allowing multi-line lambda
+   expressions which would mean a multi-line expression could suddenly
+   exist.  That would allow for multi-line arguments to function
+   calls, for instance.  That is just plain ugly.
+
    Thread: "genexp syntax / lambda",
    http://mail.python.org/pipermail/python-3000/2006-April/001042.html
 
@@ -66,6 +96,20 @@ Core language
    Thread: elimination of scope bleeding of iteration variables
    http://mail.python.org/pipermail/python-dev/2006-May/064761.html
 
+* The parser won't be more complex than LL(1).
+
+   Simple is better than complex.  This idea extends to the parser.
+   Restricting Python's grammar to an LL(1) parser is a blessing,
+   not a curse.  It puts us in handcuffs that prevent us from going
+   overboard and ending up with funky grammar rules like some other
+   dynamic languages that will go unnamed, like Perl.
+
+* No braces.
+
+   This is so obvious that it doesn't need a reference to a mailing
+   list. Do ``from __future__ import braces`` to get a definitive
+   answer on this subject.
+
 
 Builtins
 ========