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

[Paul Moore]

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 [spark_callback] (self):
> 	@spark_rule = "DOC := HEAD BODY FOOT"
> 	...
>
> def foo [publish_to_web](self):
> 	@url = "/cgi-bin/directory/directory"
>
> Otherwise you get into a lot of this stuff:
>
> def foo[publish_to_web("http://directory/directory")](self):
> 	...

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 foo[publish("http://directory/directory")](self):
        ...

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

    def foo [publish](self):
        ...
    foo.url = "http://directory/directory"

3. Needs new attribute syntax.

    def foo [publish](self):
        @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