[Python-Dev] PEP 318: Can't we all just get along? (original) (raw)
Michael Sparks Michael.Sparks at rd.bbc.co.uk
Thu Aug 19 12:32:57 CEST 2004
- Previous message: [Python-Dev] PEP 318: Can't we all just get along?
- Next message: [Python-Dev] PEP 318: Suggest we drop it
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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:
And also referenced/discussed it here:
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.
- Previous message: [Python-Dev] PEP 318: Can't we all just get along?
- Next message: [Python-Dev] PEP 318: Suggest we drop it
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]