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

[John Marshall]

On Wed, 2004-08-11 at 15:29, Bob Ippolito wrote:
> 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?
> 

I am not refering to actually executing the code but
addressing people's point that when they read through
the code, they need to keep all the decorator items in
memory until they come to the "def ...". One person
described the process as push each decorator onto
a stack (in his head) until he found the def.

> > 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)?
> 

Sure. But this addresses two concerns explicitly.

> >    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

I imagine it is possible. But the point was to make
the signature clearly visible/prominent but also indicate
that there _are_ decorators associated with the method/function.

> 
> >    d) can be located anywhere in the code--but most likely
> >       before the "def ...()"
> 
> I don't think that is a bonus at all.
> 

I am not claiming this as a bonus. Rather, I am making it clear
that the mention of the method/function name does not require
any special/forced placement.

> > 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.
> 

I am not claiming that it is obvious but that it could be
understood that way (rather than leave it to interpretation,
I made it explicit as an option). Note how the sequence issue
has come up recently with respect to the @-syntax and the list
syntax, which apparently have been understood to apply in the
opposite order.

> > This approach could also be applied to classes in case
> > decorators should ever be extended to them:
> 
> So can any of the other proposals.

That may be, but to be able to do so this way makes it
an viable option.

> 
> > -----
> > 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 :)
> 

Personally, I might opt for something else, but having the
decorators outside have raised concerns for some. With this
approach the tagging makes things explicit, which is often
a good thing. The current @-syntax _implicitly_ identifies
the decorators with the method/function/class which people
have said they don't like.

Thanks for the comments.

John

> -bob