Integrate points listed in python-dev Summary not covered in PEP.

pep-0318.txt

@@ -145,7 +145,9 @@ Design Goals
 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 @@ The new syntax should
   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 @@ The new syntax should
   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 @@ line of code has a result on a following line.  The syntax that
 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 @@ sentiment ran high, mostly because that syntax, though useless except
 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 @@ There is some history in Java using @ initially as a marker in
 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
+leading to possibly subtle semantic bugs.  It also means that ambiguity
-fairly arbitrary choice.  Some have suggested using | instead.
+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: