[Python-Dev] Re: method decorators (PEP 318)

[Paul Moore]

Guido van Rossum <guido at python.org> writes:

> We came to an interesting conclusion (which Robert had anticipated):
> there are two quite different groups of use cases.
>
> One group of use cases modifies the way the method works, its
> semantics.
[...]
> The other group of use cases merely attaches extra bits of metadata to
> the method, without changing its usage.

I don't see these as two distinct use cases for the decorator
mechanism. I would personally never use decorators for your second
case (it's possible to do so, but that's a different matter). For me,
your second use case is a use case for function attributes, not for
decorator syntax.

So in my view, your second use case is orthogonal to PEP 318, and
should not impact on it at all.

> (2) Invent some other notation for setting function attributes as part
>     of the function *body*, before the doc string even.

As I say, I think this is a red herring. Sure, having a specialised
notation for setting function attributes is a notion that has been
round for a long time. But any plausible implementation of "decorators
of the first category" is going to leave open the possibility of a
decorator like

    def attributes(**kw):
        def decorator(f):
            for k, v in kw.iteritems():
                setattr(f, k, v)
            return f
        return decorator

If the importance of the metadata use case is sufficient to justify
new syntax, then it is regardless of the existence of decorators. If
it isn't, then I can't see how the existence of decorators could make
it more important to have syntax for setting attributes.

> For (2) I am thinking aloud here:
>
>    def foobar(self, arg):
>        @author: "Guido van Rossum"
>        @deprecated
>        pass

To be perfectly honest, I think this is a lousy example. I can't see
any real reason I'd ever want to set an "author" attribute on a
function (or any other attribution-style data), other than for
documentation. And in that case, I'd probably prefer to define a
project standard for the layout of the docstring. That said, I don't
mind the syntax.

And as for the "deprecated" case, that's one I'd definitely use a
decorator for! I'd want the function wrapped to raise a "Deprecated"
warning. Just having an attribute set would do nothing at runtime. (In
another post, you mentioned a metaclass. But a decorator would work
for bare (non-method) functions, as well as methods, where a metaclass
could not).

If your only point is that decorators are not an appropriate mechanism
for setting function attributes, then I agree with this. But unless
you're proposing to somehow cripple decorators so that my attributes
decorator above is *impossible*, then that statement is simply a style
issue.

Let's keep the discussion on PEP 318 focused on decorators. I'm happy
to have it stated (in the PEP, if you like) that a decorator like
attributes is an abuse and is strongly discouraged. But I don't think
that the existence of an abuse is justification for rejection of the
feature. Heck, if that was true, then half of the features already in
Python would need removing...

My view is that the idiom of "wrapping" is a very general, and highly
useful, programming paradigm. Providing direct language support for
that idiom will make a certain class of programs easier to write, and
more understandable to read. Any general mechanism brings the risk of
abuse, but in my experience, Python programmers have always shown good
taste and restraint in the use of the language - I'd assume that the
same would be true of this feature.

Paul.
-- 
This signature intentionally left blank