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

John Marshall John.Marshall at ec.gc.ca
Wed Aug 11 17:52:26 CEST 2004

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

More information about the Python-Dev mailing list