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

Paul Moore pf_moore at yahoo.co.uk
Fri Mar 26 18:48:48 EST 2004

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

More information about the Python-Dev mailing list