[Python-Dev] method decorators (PEP 318)

Guido van Rossum guido at python.org
Fri Mar 26 13:37:58 EST 2004


> It's apparent Guido doesn't agree; I just wish I knew what was
> bothering him about the PEP, so I could either provide a convincing
> counterargument, or understand better why I'm wrong.  <0.5 wink> At
> the moment, I'm worried that something in my actual use cases will
> scare him into rejecting the PEP altogether.  <0.01 wink>

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).  I would much rather
see this:

  def foobar [classmethod] (cls, blooh, blah):

I agree that if this will be used for decorators with long argument
lists, putting it in front of the arguments is worse than putting it
after, but I find that in that case the current PEP favorite is also
ugly:

  def foobar (self, blooh, blah) [
      metadata(author="GvR",
               version="1.0",
               copyright="PSF",
               ...),
      deprecated,
  ]:
      for bl, oh in blooh:
          print oh(blah(bl))

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.

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

--Guido van Rossum (home page: http://www.python.org/~guido/)



More information about the Python-Dev mailing list