[Python-Dev] A decorator syntax not yet mentioned (I think!)

Bob Ippolito bob at redivi.com
Wed Aug 11 17:29:50 CEST 2004

On Aug 11, 2004, at 11:16 AM, John Marshall wrote:

> How about the following, which I am almost positive
> has not been suggested:
> -----
> class Klass:
>     def __init__(self, name):
>         self.name = name
>     deco meth0:
>         staticmethod
>     def meth0(x):
>         return x
>     deco meth1:
>         classmethod
>     def meth1(cls):
>         return cls
>     deco sayhello:
>         funcattrs(name='GvR', language='python')
>         log(file='func.log')
>     def sayhello(self):
>         print 'hello python world'
> -----
> 1) The decorators clearly apply to a specific method/function,
>    therefore there is no need to do any stack pushing in memory
>    until the method/function definition is done.

None of that code can actually execute until the method/function 
definition is done, how is this different at all?

> 2) The decorators are "outside" of the method/function they
>    decorate:
>    a) which will please those who want the outside location
>    b) will not be folded within the function

Doesn't a) imply b)?

>    c) folding on the decorators can be done so that the
>       def is not obfuscated

This could probably be done with the @syntax too if the editor was 
smart enough

>    d) can be located anywhere in the code--but most likely
>       before the "def ...()"

I don't think that is a bonus at all.

> 3) The sequence in which the decorators are applied is just
>    like code would be--this is certainly intuitive given
>    that we are writing code.

That's not really obvious.

> This approach could also be applied to classes in case
> decorators should ever be extended to them:

So can any of the other proposals.

> -----
> deco Klass:
>     doc("This is a class to ...")
> class Klass:
>     :
>     :
> -----
> Any comments?

Yeah, this is no less than twice as bad as any of the current decorator 
proposals because you have to repeat the function name :)


More information about the Python-list mailing list