Purely emotional perspective

Heiko Wundram heikowu at ceosg.de
Mon Aug 9 12:53:48 EDT 2004


Am Montag, 9. August 2004 18:03 schrieb Peter Hansen:
> After a while, when everyone is used to decorators, it won't
> be important to have them way out front like that, and they
> could just as well, and perhaps more readably (at that time),
> be moved to after the def.

I don't think this is true... Decorators are not simply "meta-data" that is 
attached to a function, they change the functions behaviour. As such, they 
create a different function than the one which is declared.

Consider:

def somedecorator(f):
	def fdec(*args,**kwargs):
		return f("somearg",*args,**kwargs)
	return staticmethod(fdec)

With definitions:

class x(object):

	def y(some,arg):
		@ somedecorator
		<blah>

Versus:

class x(object):

	@ somedecorator
	def y(some,arg):
		<blah>

Now, say you folded out the body of x with some form of decent editor. In the 
first example, @somedecorator disappears, as it is part of the function body, 
in the second example, it stays in (and I wouldn't want an editor to fold out 
the decorating statements for a function, and it would be kind'a hard to have 
a sensible way for the editor to display the first few lines decorating the 
function inside the function body while the function is folded out).

What the catch is: somedecorator does not only change the function "type", as 
you would consider staticmethod or classmethod do, but also changes the 
function signature, as the first argument to the function is fixed by the 
decorator (I actually have use cases for this).

Now, it is very important that at first glance you see that the function only 
takes one parameter (as it is decorated by somedecorator), and this only 
stands out clearly in the second example (at least for my taste), if you know 
what somedecorator does, obviously.

The docstring of a function actually is only meta-data (in my taste), and thus 
should remain inside the function definition.

When and how decorators do something to the method is unimportant to my taste 
(they are executed after the function definition has been executed), but 
visibly seeing that the decorator is being applied to the function is much 
easier for the second syntax.

I won't try to throw in some form of debate about the character used to 
attribute decorators, but I'm for @, because it stands out much more than | 
does.

Anyway, my 2 cents...

Heiko.



More information about the Python-list mailing list