[Python-Dev] method decorators (PEP 318)

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