Purely emotional perspective

[Michael J. Fromberger]

In article <XqSdnTW-4KvRIIrcRVn-jQ at powergate.ca>,
 Peter Hansen <peter at engcorp.com> wrote:
> 
> Python is clearly on a huge evolutionary surge and conservative views
> on the matter are definitely not winning out right now.  And the usual
> argument (submit a patch!) doesn't really work when those who want to
> avoid many changes try it... I've been *not* submitting a patch on
> lots of changes to Python, but somehow it's never been accepted. ;-)

I think you are right, Peter, about the pressure to change the nature of 
Python, and the resistance to conservatism about doing so.

I have been following the explosion of discussion on this subject with 
some concern, because I think this whole "decorators" proposal is a 
misguided attempt to conflate several orthogonal goals under the aegis 
of a single new mechanism.  I do not believe it is wise to aggregate the 
notations for descriptive meta-data (author, version number, etc.) with 
those of type-constraints, of method qualifiers, or any other such 
code-generation annotations.

Much of the discussion has focused on the visual appearance of this new 
construct, but I think that's a red herring -- its problems run much 
deeper than that.  Even assuming we can find a suitably harmonious 
notation for it, I remain unconvinced that "decorators" as currently 
specified deserve to be added to Python.  Assuming we take the Zen of 
Python as a set of philosophical design goals for Python, I argue that 
all the proposed uses of decorators so far fail the Zen on the following 
axes:  Beauty, Simplicity, Sparseness, Readability, Special Cases, One 
Obvious Way, and Difficulty of Explanation.

The stated Motivation of PEP-318 is, essentially, to visually conjoin 
the translation of functions into class or static methods with the 
definition of the function itself.  Oh, and by the way, maybe we could 
also use this for some other annotations we'll think up later -- but 
for now, that's pretty much it (http://www.python.org/peps/pep-0318.html).  
Do we really need this small change so badly that we're willing to open
the door to every half-baked hunk of function and method meta-data 
somebody can imagine?

Let's stop bickering about syntax for a moment, take a deep breath, and 
back up a pace.  Does Python really need this?  I say no:  Even if we 
come up with a good syntax, I do not think decorators, as they are being 
described and implemented as we speak, are a good idea.  Some of the 
ideas people want to use them for are reasonable, but I think we should 
be rational about it, and keep orthogonal concerns appropriately 
separated. 

-M

-- 
Michael J. Fromberger             | Lecturer, Dept. of Computer Science
http://www.dartmouth.edu/~sting/  | Dartmouth College, Hanover, NH, USA