[Python-Dev] def ... decorate
jack at performancedrivers.com
Fri Aug 13 23:31:00 CEST 2004
On Fri, Aug 13, 2004 at 02:51:37PM -0500, Skip Montanaro wrote:
> I understand that not everyone will like every idea and that in this
> particular arena it seems that no one idea is acceptable to everyone, but
> can we return to my proposal and discuss its pros and cons? I didn't pick
> the example out of thin air. I cast an existing example from c.l.py in this
> form (thus the function name and somewhat unusual collection of decorator
> names). The only thing I added besides the syntax change was to identify
> where I thought the docstring should go.
> def p_statement_expr:
> grammarrule('statement : expression')
> version("Added in 2.4")
> decorate (self, p):
> """docstring here"""
> print p
> I understand that it has obvious weaknesses as well:
> * It separates the function name from its parameter list. That does
> allow us to aboid parsing ambiguities though.
This is huge, it would mean two ways to do it. When I want to decorate the
function with '@' I add an extra line above the existing definition.
With this suggestion I have to pick the line apart and shuffle stuff around.
Guido has said being able to add/remove a decorator should be as simple as
cut/pasting a line and I agree.
> * It can't readily be extended to class definitions, though the demand
> for that seems minor and mostly argued for symmetry reasons.
Class decorators are pretty important to me. I would replace most of my meta
class usages with decorators. I care enough I spent two days writing a patch
and fishing through the bowels of compile.c (*plug plug*).
* It uses a suite in a way different from all other suites.
A group of points
* it breaks grepability badly
* it breaks existing tools by radically changing the grammar
* breaking machine tools also means breaking meat tools. I now have to fit
two ways of recognizing functions in my head all the time. This is the
showstopper of all showstoppers right there.
More information about the Python-Dev