[Python-Dev] PEP 318 - check for consensus

[Guido van Rossum]

> The decorator discussion has gotten lively again, 
> and a summary would be a long list of options.

Really?  If feels pretty quiet here on python-dev.

> I'm hoping that at least some of the decisions are
> non-controversial.  If you have an opinion on the 
> following, please email me directly (to not clutter 
> the list).  If several people disagree (or some
> disagree strongly), I'll consider the issue still
> undecided.
> 
> 	Issue 1:  When is the name bound?
> 
> The current proposal is that the name does not get
> bound until after the final decorator is applied.
> This means that decorators do not have access to
> the function by its name.  
> 
> They can learn the name, perhaps through sys._getframe, 
> but the name will not yet be bound, unless it happens
> to refer to an unrelated object.  (See issue two for
> a better way to get the name.)

A function's name is accessible through its __name__ attribute and
also as func_name.  I think that's quite enough. ;-)

> Does anyone feel strongly that the name should be 
> bound to the original function before decorators are
> applied?
> 
> Does anyone feel strongly that the name should be
> bound to the result of each intermediate step, if
> there are multiple decorators?

No.  The function should not be bound until after all decorators have
been applied.

> 	Issue 2:  Restrictions on decorators
> 
> The working assumption had been "any callable, which
> will be called with a single object as the argument"
> 
> 	Issue 2a:  name of the entry point
> 
> Is there a strong feeling (in any direction) about 
> calling the decorator's "decorate" or "__decorate__"
> attribute, rather than its "__call__" attribute?

It should be __call__; that's the only backwards compatible way, and
makes it easy to create decorators as functions.

> 	Issue 2b:  context available to decorators
> 
> Would there be any objection to passing additional
> context as keywords?  
> 
> decorate(object, name="myfunc")
> 
> The obvious keywords are the name and the context's
> globals; decorators should probably accept arbitrary
> keywords for forward-compatibility.

That's unnecessary; see answer to #1.

--Guido van Rossum (home page: http://www.python.org/~guido/)