[Python-checkins] r46597 - peps/trunk/pep-3099.txt
georg.brandl
python-checkins at python.org
Thu Jun 1 20:50:00 CEST 2006
Author: georg.brandl
Date: Thu Jun 1 20:49:59 2006
New Revision: 46597
Modified:
peps/trunk/pep-3099.txt
Log:
Fold PEP 13 draft into PEP 3099.
Modified: peps/trunk/pep-3099.txt
==============================================================================
--- peps/trunk/pep-3099.txt (original)
+++ peps/trunk/pep-3099.txt Thu Jun 1 20:49:59 2006
@@ -12,17 +12,47 @@
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 @@
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
========
More information about the Python-checkins
mailing list