compromise? keywords for static/class, move decorators to top of function

Larry Bates lbates at
Mon Aug 9 16:03:57 CEST 2004

There are a lot of people talking about decorators
that I'm certain are a LOT smarter than me but here

Couldn't we use a dictionary construct like the one
used in classes to hold the dictionaries attributes.
I'm talking about __dict__ construct.

def getratio(arg1, arg2):
    __decorators__['getratio']={} # Maybe this is automatic?
    # or __decorators__['getratio']=__decoratorbase__.copy()
    __decorators__['getratio']['accepts']=(int, int)
    __decorators__['getratio']['metadata1']="some metadata"

I'm sure I'm missing something but this seems to
be 1) Easy on my eye, 2) Extensible (any metadata
that you want), 3) Consistent with something I'm
already comfortable with.

I'm certain that I'm missing something very important, but
I have to agree with many others, the '@' syntax just
doesn't feel correct.

Larry Bates
Syscon, Inc.

"Doug Holton" <insert at> wrote in message
news:Oo2dnUOZI8VmWI7cRVn-sA at
> First let me say please see the wiki page about python decorators if you
> haven't already:
> I propose (and others have) that built-in features have keyword support,
> like static and class methods.  Also, I believe it is more readable if
> decorators, especially longer ones, are moved to the top of the function
> body, just like docstrings, instead of coming before the function is
> even declared.  Whether you use @ or [] is still open.
> def classmethod getratio (arg1, arg2):
>      @accepts(int,int)
>      @returns(float)
>      ...
> def classmethod getratio (arg1, arg2):
>      [accepts(int,int), returns(float)]
>      ...
> This has these advantages: the function declaration itself is still the
> first and most important thing, decorators are indented just like the
> body of the function so it is more clearly a part of the function.
> In the future though, if you add an "as" keyword for adapters, you could
> just say:
> def classmethod getratio (arg1 as int, arg2 as int) as float:
>      ...
> contrast that simple example with this, which is kind of ugly:
> @accepts(int,int)
> @returns(float)
> @classmethod #has to be last in order?
> def getratio (arg1, arg2):
>      ...

More information about the Python-list mailing list