[Python-Dev] method decorators (PEP 318) (original) (raw)

Jack Diederich 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 function.)

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.

-jackdied



More information about the Python-Dev mailing list