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

Paul Prescod paul at prescod.net
Sat Mar 27 18:30:43 EST 2004


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.

You see some use cases as being appropriate for the decorator syntax and 
some for another function attribute syntax.

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?

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.

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):
	...


  Paul Prescod





More information about the Python-Dev mailing list