[Python-Dev] method decorators (PEP 318)

[Guido van Rossum]

> >For (2) I am thinking aloud here:
> >
> >    def foobar(self, arg):
> >        @author: "Guido van Rossum"
> >        @deprecated
> >        pass
> 
> Who is the metadata *for*?  Is it just for a human readers and 
> documentation tools?  Or is it intended for machine consumption as well?

Doc tools are machine consumption too, right?  I'd say for both.  This
stuff should definitely be accessible at runtime (it is in C# and JDK
1.5).  And one shouldn't have to do any parsing of doc strings at run
time.  There are no uses of function attributes that *couldn't* be
replaced by putting structured information into the doc string, but
IMO that misses out on the usefulness of function attributes.

> If it's for the machine, IMO it should be the same syntax, without a
> new construct.  If it's for humans and documentation tools, why
> shouldn't it go in the docstring?

Perhaps my example was a little simplistic.  The C# examples put the
author/version info in an object; in Python, this would translate to
something like:

  def foobar(self, arg):
      @author: AuthorInfo(author="GvR", version="1.0", copyright="GPL", ...)
      @deprecated: True

I could also see using '=' instead of ':':

  def foobar(self, arg):
      @author = AuthorInfo(author="GvR", version="1.0", copyright="GPL", ...)
      @deprecated = True

> I guess I don't understand why you see these use cases as so
> different from each other as to deserve different syntax, but not
> different enough to just use the docstring.  In other words, why not
> simply treat:
> 
>      def foobar(self, arg) [
>          info(author="Guido van Rossum", deprecated=True)
>      ]:
>          pass
> 
> as a straightforward application of the same mechanism?  Why make
> people have to learn two mechanisms, one of which is limited to
> function attributes, and the other of which is awkward to use with
> multiple items?

I find the mark-up in your example about the worst possible mark-up;
in practice, these things can get quite voluminous (we're only
restricting ourselves to a single item that fits on a line because
we're used to giving minimal examples).  I would hate it if something
*semantically* significant like classmethod or synchronized had to
compete for the user's attention with several lines of structured
metadata.

> C# and Java aren't dynamic languages - they don't treat functions or
> methods as first class objects, so of course they don't support any
> sort of transformation, and are limited to passive metadata in their
> attribution syntax.  But dynamic frameworks in Python want to be
> able to have "active attribution".  A number of people here have
> presented examples of things where they want to have decorators call
> a framework function to register the current function, method, or
> class in some way.  Function attributes don't support this - you
> still have to call something afterwards.

A framework-supplied metaclass could easily be designed to look for
function attributes set with this mechanism.  (One could also imagine
a metaclass-free hybrid approach where there's a transformer placed in
the decorator list which looks for function attributes to guide its
transformation.)

And yes, this could also be used to declare class and static methods
(by putting something in the standard metaclass that looks for certain
function attributes, e.g. @wrap=classmethod) but I still think that
these "wrapper descriptors" are better served by a different syntax,
one that is more integrated with the function signature.

> I don't believe that the interest in decorators is simply to support
> classmethod et al, or to have a way to do function attributes.
> Instead, they're a workaround for the fact that Python function
> definitions aren't expressions.  Otherwise, we'd be doing things
> like this monstrosity:
> 
>      foobar = classmethod(
>          def (self,arg):
>              pass
>      )
> 
> Obviously, I'm not arguing that Python should look like Lisp.  The
> current decorator syntax patch is *much* easier to read than
> wrapping an entire function definition in parentheses.  But the
> semantics that I think most people are asking for with decorators,
> is the simple Lisp-like capability of applying transformations to a
> function, but with a more Pythonic syntax.  That is, one where flat
> is better than nested, and readability counts.  That is the use case
> that decorators are intended to serve, IMO, and I believe that this
> is what most other proponents of decorators are after as well.

I would like to see more examples of that use case that aren't
classmethod and aren't mutually exclusing with most other examples.
The PEP stops with the arg checker example, and that's not a very
convincing one (because it's so clumsy for that particular goal).

> Function attributes, on the other hand, don't really address these
> use cases.  I would ask, how much field use of function attributes
> exists today?  Versus how much use of built-in and homemade
> decorators?  There are lots of the latter, and very few of the
> former.

I think this isn't a fair comparison.  Python 2.2 introduced several
built-in decorators, and machinery to build your own, creating a
cottage industry for home-grown decorators.  No similar promotion was
given to function attributes when they were introduced in Python 2.1.
But using decorators as a way to set attributes (as in PEP 318 example
3) is ass-backwards.

> I would also guess that where people are using function attributes,
> there's a good chance that they're using decorators as well, since
> they probably need to *do* something with the attributes.

Depends entirely on the usage.  Maybe you're thinking of some of your
own usage?  (I'm still not familiar with PEAK, nor will I have time to
read up on it any time soon, so please don't just refer to PEAK
without being specific.)

> Considering that both function attributes and decorators have the
> same overhead today for use (i.e., put them at the end, no special
> syntax available), that would suggest that the need/desire for
> decorators is much greater than the need for mere metadata
> annotation.

I'm not convinced.  I expect that if we had good syntax for both, we
would see more use of attributes than of decorators, except perhaps in
meta-heavy frameworks like PEAK.

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