[Python-Dev] Re: Re: Call for defense of @decorators

[Chris King]

On Tue, 10 Aug 2004 08:40:59 +1000, Delaney, Timothy C (Timothy)
<tdelaney at avaya.com> wrote:

> Not such a large outcry, but lots of us were concerned about "having to look inside the function for 'yield' to determine if it were a generator or a function" and were calling for a 'gen' or 'generator' keyword.

Building off of this:

It's not really that important to a user to know whether a function is
a generator or not: the difference (to a user) is the same difference
as whether a function returns a single item or a list.  A function's
return type isn't visibly declared at the top of the function, it
(along with everything else you need to know when calling a function)
is in the docstring.

Now, is it really that important to a user whether a method is a class
or static method?  They're all called the same way (so long as they're
bound), and most users couldn't care less how a function is
implemented.  If the distinction is really important to the user, then
they will presumably be prudent enough to check for this by looking
either just below the function name (or wherever decorators end up),
or by reading the docstring if the function author decided to document
that.

What's more, aside from classmethod and staticmethod, most other
decorations will be for the module's own use.  Placing such
insignificant (to the user!) details such as these above the
function's name and signature (what I think is the most important
aspect of a function!) just seems like we're asking for obfuscation.

A counter argument may be that decorators need to be readily visible
to module authors.  Well, to the author of a module, I'd say the code
is the most important aspect of a function -- module authors should be
worrying more about why their calculate_pi() funcion is returning
3.24895, rather than whether it's a class or static method.  Of
course, the error could have been caused by a misdeclaration of method
type, but I'm sure that would be the cause much less often than, say,
an off-by-one error in the code.

+1 for decorators anywhere after the function name and signature, even
if it involves pies.