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

Paul Moore pf_moore at yahoo.co.uk
Sun Mar 28 06:51:59 EST 2004

Paul Prescod <paul at prescod.net> writes:

Paul Moore wrote:

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. You've phrased your mail as if you were disagreeing, but it sounds to me like you are agreeing.

Hmm, maybe. I was disagreeing with the idea that the two issues need to be treated together. I'm OK with the idea that using a decorator to set function attributes being an abuse. But that didn't seem to me to justify complicating the existing PEP with issues of new syntax for setting function attributes.

Guido's proposal explicitly defined two unrelated syntaxes for two unrelated features dealing with these two unrelated use cases. Rather than arguing with him, you should be supporting him. The people you should be arguing with are people who want to use one syntax for both, because this will lead to a design which is suboptimal for what you call "true decorators".

>... 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. Who is talking about rejecting any feature?

You have a good point here. But Guido is on record as feeling vaguely uncomfortable about decorators. I read his proposal as implying that the existing decorator proposal needed to be somehow restricted, so that it couldn't be used for the unrelated case of attribute setting.

I may have read too much into Guido's proposal.

Anyhow, I do not believe that the two features are as unrelated as you think.

First: we do not want to introduce a new feature that will ENCOURAGE abuse. Better to introduce two features and head that off at the pass.

That is where the "rejection" implication comes in. We've just started a whole new thread on syntax for setting function attributes. If that issue gets too complex to resolve before 2.4, would you support holding off on decorators until it is resolved? I wouldn't.

Second: I see use cases like this:

def foo [sparkcallback] (self): @sparkrule = "DOC := HEAD BODY FOOT" ... def foo publishtoweb: @url = "/cgi-bin/directory/directory" Otherwise you get into a lot of this stuff: def foopublishtoweb("http://directory/directory"): ...

That is a very good point - in effect, most parametrised decorators can be converted into a combination of a non-parametrised decorator and one or more function attributes. (And with a suitable attribute syntax, the result is more readable).

I'd fully support this.

But, I repeat: if attribute setting syntax gets bogged down in endless discussion, I'd rather see decorators in now, and it should be made clear to people who write parametrised decorators that they should change to an attribute-based approach once the syntax becomes available.

After all, the syntax and semantics of decorators won't change, so why wait?

Actually, there are 3 options:

  1. Available as soon as decorators are:

    def foopublish("http://directory/directory"): ...

  2. Available as soon as decorators are, but still has significant information at the end of the function body

    def foo publish: ... foo.url = "http://directory/directory"

  3. Needs new attribute syntax.

    def foo publish: @url = "http://directory/directory" ...

My preference is for (2), with (3) being the long-term solution when new syntax is available. I agree that (1) is ugly and difficult to read, but I'm not sure that will stop some people :-)

Can the PEP be updated to show option (2) in use, and recommend it over option (1). Then, the possibility of implementing option (3) could be noted in the "Open Issues" section.

Paul.

This signature intentionally left blank

More information about the Python-Dev mailing list