[Python-checkins] python/nondist/peps pep-0318.txt,1.24,1.25

Tue Aug 24 07:50:05 CEST 2004

Update of /cvsroot/python/python/nondist/peps
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv30454
Modified Files:
	pep-0318.txt 
Log Message:
Integrate points listed in python-dev Summary not covered in PEP.
Index: pep-0318.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0318.txt,v
retrieving revision 1.24
retrieving revision 1.25
diff -u -d -r1.24 -r1.25

--- pep-0318.txt	20 Aug 2004 01:18:24 -0000	1.24
+++ pep-0318.txt	24 Aug 2004 05:50:01 -0000	1.25
@@ -145,7 +145,9 @@
 The new syntax should
 
 * work for arbitrary wrappers, including user-defined callables and
- the existing builtins ``classmethod()`` and ``staticmethod()``
+ the existing builtins ``classmethod()`` and ``staticmethod()``. This
+ requirement also means that a decorator syntax must support passing
+ arguments to the wrapper constructor
 
 * work with multiple wrappers per definition
 
@@ -153,6 +155,8 @@
 obvious that new users can safely ignore it when writing their own
 code
 
+* be a syntax "that ... [is] easy to remember once explained"
+
 * not make future extensions more difficult
 
 * be easy to type; programs that use it are expected to use it very
@@ -166,6 +170,11 @@
 language-sensitive editors and other "`toy parser tools out
 there`_"
 
+* allow future compilers to optimize for decorators. With the hope of
+ a JIT compiler for Python coming into existence at some point this
+ tends to require the syntax for decorators to come before the
+ function definition
+
 * move from the end of the function, where it's currently hidden, to
 the front where it is more `in your face`_
 
@@ -251,9 +260,20 @@
 will be in 2.4a3 will also require one decorator per line (in a2,
 multiple decorators can be specified on the same line).
 
+People also complained that the syntax got unwieldly quickly when
+multiple decorators were used. The point was made, though, that the
+chances of a large number of decorators being used on a single function
+were small and thus this was not a large worry.
+
 Some of the advantages of this form are that the decorators live
 outside the method body -- they are obviously executed at the time
-the function is defined
+the function is defined.
+
+Another advantage is that being prefix to the function definition fit the
+idea of knowing about a change to the semantics of the code before the
+code itself, thus knowing how to interpret the code's semantics
+properly without having to go back and change your initial perceptions
+if the syntax did not come before the function definition.
 
 The second form is the decorators between the def and the function
 name, or the function name and the argument list::
@@ -456,6 +476,13 @@
 for side effects of the list, is already legal and thus creates a
 special case.
 
+One attraction people later had to the syntax, though, was the
+possibility of implementing a backwards-compatible implementation of
+decorators so that versions prior to 2.4 (back to 2.2) could also use
+the new syntax. But it was decided this was not a valid argument;
+Since the feature is new it should not be restricted just so that
+previous versions could possibly use it.
+
 .. _list of decorators:
 http://python.org/sf/926860
 
@@ -502,8 +529,9 @@
 are similar to Python decorators. The fact that @ was previously
 unused as a token in Python also means it's clear there is no
 possibility of such code being parsed by an earlier version of Python,
-leading to possibly subtle semantic bugs. That said, @ is still a
-fairly arbitrary choice. Some have suggested using | instead.
+leading to possibly subtle semantic bugs. It also means that ambiguity
+of what is a decorator and what isn't is removed. of That said, @ is
+still a fairly arbitrary choice. Some have suggested using | instead.
 
 For syntax options which use a list-like syntax (no matter where it
 appears) to specify the decorators a few alternatives were proposed:
