[Python-checkins] peps: Tweak the equivalence example, explain why a nested suite is a bad idea
nick.coghlan
python-checkins at python.org
Mon Sep 3 14:09:40 CEST 2012
http://hg.python.org/peps/rev/9f8c31db2b19
changeset: 4505:9f8c31db2b19
user: Nick Coghlan <ncoghlan at gmail.com>
date: Mon Sep 03 22:09:30 2012 +1000
summary:
Tweak the equivalence example, explain why a nested suite is a bad idea
files:
pep-0403.txt | 27 +++++++++++++++++++++++++--
1 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/pep-0403.txt b/pep-0403.txt
--- a/pep-0403.txt
+++ b/pep-0403.txt
@@ -130,12 +130,14 @@
Under this PEP, an ordinary class or function definition::
+ @deco2
+ @deco1
def name():
...
-would be equivalent to::
+can be explained as being roughly equivalent to::
- @in name = name
+ @in name = deco2(deco1(name))
def name():
...
@@ -214,6 +216,27 @@
actual name binding in the current scope.
+Why not a nested suite?
+-----------------------
+
+The problem with using a full nested suite is best described by reviewing
+PEP 3150. It's ridiculously hard to implement properly, and creates way
+too many situations where there are two ways to do it (almost any construct
+that can be expressed with ordinary imperative code could instead be
+expressed using a given statement).
+
+By contrast, the decorator inspired syntax explicitly limits the new
+feature to cases where it should actually improve readability, rather than
+harming it. As in the case of the original introduction of decorators, the
+idea of this new syntax is that if it *can* be used (i.e. the local name
+binding of the function is completely unnecessary) then it *should* be used.
+
+While a non-decorator based alternative could be considered (e.g. a nested
+"suite" that actually allowed only a single class or function definition),
+it seems excessive to introduce a completely new concept when it is
+possible to use a variant of the existing decorator syntax instead.
+
+
Keyword Choice
--------------
--
Repository URL: http://hg.python.org/peps
More information about the Python-checkins
mailing list