Purely emotional perspective

[Peter Hansen]

Heiko Wundram wrote:

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

Actually, the first example could just as well have been this:

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

But I can just hear the arguments against that, much as I like it.

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

I *would* like decorators to be folded, I think, if I were in the habit
of using folding editors.  But I'm fairly sure it wouldn't be hard to
avoid folding @ lines that immediately follow the :, or for that matter
that come just before it.  The real issue here (not that it bothers me)
is that a lot of editors are probably tied to the idea that the : comes
right after the argument list or something, so they probably would have
to be redone to handle pre-colon decorators.

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

This argument makes no sense to me.  Why should any meta-data be inside
the function body?  There should probably be one place where all
meta-data is defined, and it should be used consistently for everything,
docstrings included.  (The pie-syntaxians are heading that way, it
seems.)

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

To tell the truth, I think I prefer the current approach, where the
function is clearly, explicitly decorated *after* it has been defined,
and no new syntax is required.

Python is clearly on a huge evolutionary surge and conservative views
on the matter are definitely not winning out right now.  And the usual
argument (submit a patch!) doesn't really work when those who want to
avoid many changes try it... I've been *not* submitting a patch on
lots of changes to Python, but somehow it's never been accepted. ;-)

-Peter