[Python-Dev] PEP 318: Can't we all just get along?

[Michael Sparks]

Guido,


On Thursday 19 Aug 2004 05:01, Guido van Rossum wrote:
> Is anybody seriously trying to come up with a single alternative
> decorator proposal that most folks "out there" can support, to be
> presented to me (with implementation, please!) in time for 2.4b1?

Yes. The following syntax discussed on comp.lang.python struck me as having
legs so I produced an implementation.  Hopefully this email summarises the 
resulting discussion so far adequately, and if you have a moment, an answer 
to the question I pose at the end of this email would be very welcome. 

To me, this syntax appears to retain the advantages of @decorator whilst
having some clear benefits for new users, or people who only occasionally
look at python for maintenance. A number of old hands have said they too
like this syntax, and couple of others who said they think it's too
heavyweight have so far rated it -0.

Example:

# This is syntax J2 from http://www.python.org/moin/PythonDecorators
decorate:
     staticmethod
     grammarrule('statement : expression')
     versioninfo("Added in 2.4")
     deprecated
     typeinfo(None)
def p_statement_expr(self, p):
     print p[1]

# Single line form, suggested by Paul Du Bois, Nick Coghlan
decorate: staticmethod 
def p_statement_expr(self, p):
   pass

This prompted me to look at the source for the first time and I've posted an 
initial implementation (for discussion purposes) here:
   * http://mail.python.org/pipermail/python-list/2004-August/233591.html

And also referenced/discussed it here:
   * http://mail.python.org/pipermail/python-dev/2004-August/047807.html

There is one issue outstanding with this implementation -- for some reason the 
change in indent level means that scoping errors occur unless you force the 
functions into scope thus:

=========================
class Foo:
   staticmethod # This is cruft to force staticmethod into scope

   decorate:
      staticmethod
   def hello(who):
      print "woo?", who

Foo.hello("HOO")
=========================

I have held back on finishing this off because I'd like to hear whether it is 
an acceptable alternative to people.

So far people who have expressed opinions on this syntax in since I posted the 
link to the implementation are:

Bob Ippolito
   * Voted -0, too heavyweight for simple case

Paul Du Bois,
   * Suggested single line for for simple case, and also stated "This is my
     favorite proposal so far."

Barry Warsaw,
   * Voted -0, same reasons as Bob, _softened_ on thought of everything on
     single line for simple case with reservations on keyword.

Nick Coghlan,
   * Liked the fact it simplifies folding for editors, also suggested single
     line for simple case

Robert Brewer,
   * Prompted me to forward the implementation/suggestion to this list, and
     has offered to help drum up support for this, and put forward a complete
     proposal!

(apologies if I've summarised things inaccurately...)

Single line form suggested for the simple case was:

decorate: staticmethod
def p_statement_expr(self, p):
   pass

The key reasons I prefer this slightly more verbose version are:
   1 In the complex case, it makes it clearer to see where the function begins

   2 The simple cases, such as staticmethod & classmethod, are very unusual
      definitions for general code. The fact that this is more heavyweight 
      makes the staticmethod/classmethod decorator jump out at you more
      when skimming code. (especially unfamiliar code) To me this increases
      readability. Naturally the sacrifice there is an extra burden at writing
      time.

   3 It gives someone something concrete to search for when looking for help:
      eg "python decorate" vs "python @"

One clear possible downside:
   * Like @decorator these can only be declarations, not statements. This in
     itself might be confusing. This ambiguity does not exist with @decorator
     in my opinion.

Regarding 1, compare the following two hypothetical pieces of code. The 
comment block before the function deliberately attaches to the function 
because some code documentation tools I've seen will take such blocks and 
include them in the docs as well as doc strings. (Meaning doc strings can be 
short/focussed)

#Syntax J2 from http://www.python.org/moin/PythonDecorators
#Some random comment
#More random comment
decorate:
     staticmethod
     grammarrule('statement : expression')
     versioninfo("Added in 2.4")
     deprecated
     typeinfo(None)
def p_statement_expr(self, p):
     print p[1]

Using current syntax:

#Current syntax in 2.4a2
#Some random comment
#More random comment
@staticmethod
@grammarrule('statement : expression')
@versioninfo("Added in 2.4")
@deprecated
@typeinfo(None)
def p_statement_expr(self, p):
     print p[1]

I think other arguments I'd put forward are probably more aesthetic than 
practical.

As noted above, I have held off resolving the (hopefully) minor scoping issues 
since I'd wanted to hear if this is an acceptable alternative.  The responses 
so far make me think that it is acceptable to people if the simple case has 
the single line form available, but there are reservations due to the keyword 
requirement.

If you have a moment, I would very much appreciate an indication as to
whether you would reject this at this stage or not?

Best Regards,


Michael.
-- 
Michael Sparks, Senior R&D Engineer, Digital Media Group
Michael.Sparks at rd.bbc.co.uk,
British Broadcasting Corporation, Research and Development
Kingswood Warren, Surrey KT20 6NP

This e-mail contains personal views which are not the views of the BBC.