[Python-Dev] method decorators (PEP 318)
jack at performancedrivers.com
Fri Mar 26 14:39:10 EST 2004
On Fri, Mar 26, 2004 at 10:37:58AM -0800, Guido van Rossum wrote:
> Let me try to explain what bothers me.
> If we were going to use this mostly for decorators spelled with a
> single work, like classmethod, I would favor a syntax where the
> decorator(s) are put as early as reasonable in the function
> definition, in particular, before the argument list. After seeing all
> the examples, I still worry that this:
> def foobar(cls, blooh, blah) [classmethod]:
> hides a more important fact for understanding it (classmethod) behind
> some less important facts (the argument list).
Until now the fact that the first argument was 'cls' instead of 'self'
was the signal to the user that it was a classmethod. If there wasn't
a foobar = classmethod(foobar) a dozen lines down people would actually
be suprised and consider the declaration broken.
classmethod is currently a red-headed stepchild of a modifier, hidden
far from the defition but people still manage. I don't think because it
has been neglected for so long we need to make it _more_ important that
the arg list, as a reparation.
> I don't see a way to address both separate concerns (hiding the most
> important fact after the signature, and the ugliness of long complex
> lists of decorators) with a single syntactic alternative. The two
> concern are in conflict with each other. That's why I'm trying to
> pull the proposal apart into two directions: put small decorators in
> front, put large function attribute sets in the body.
I don't think the decorators are the most important part of the
declaration, so I prefer them after. The docstring being after the
function declartion doesn't bother me, but in a previous life
I spent doing C++ not having the documentation before the function/class
was a hanging offense.
> (For those worried that the function attribute sets appear to belong
> to the body, I point to the precedent of the docstring. IMO the start
> of the function body is a perfectly fine place for metadata about a
I think people are talking about different kinds of metadata.
functional metadata looks good inline (classmethod, register, memoize)
with the function definition
documentation metadata (author, and pydoc stuff like @returns) looks
good after the declaration. People are used to seeing it there too,
because that's where docstrings are.
I'm happy w/ docstrings for documentation metadata, I would only
use decorators for functional metadata (changing behavior). So
I like the inline w/ the function def.
More information about the Python-Dev