[Python-Dev] PEP 318 - check for consensus

[Phillip J. Eby]

(I'm replying to this on the list because there are a couple of errors in 
it regarding names and scopes, and you probably don't want the private 
votes you get to be based on misunderstandings.)


At 11:27 AM 4/14/04 -0400, Jewett, Jim J wrote:

>         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,

Actually, they can learn the name via the 'func_name' or '__name__' 
attribute of the function.  sys._getframe is only needed to access any 
*previous* binding of the name, or to do other magic in the class or module 
namespace.


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

A strong -1 on both questions.  The name should not be bound until after 
all decorators have completed.  Nobody has presented any use cases for 
early binding of the name, but several use cases for late binding the 
name.  Also, all actual implementation patches to date implement the late 
binding.


>         Issue 2:  Restrictions on decorators
>
>The working assumption had been "any callable, which
>will be called with a single object as the argument"

Yes.  However, Mike Pall's suggestion of an e.g. '__decorate__' member has 
some very appealing characteristics, with the downside of requiring a more 
complex implementation.


>         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?

+0.5.  I like it, but not enough to want to take the time to write a new 
patch to implement it, at least not this month.  :)


>         Issue 2b:  context available to decorators
>
>Would there be any objection to passing additional
>context as keywords?

Only that builtin decorators like classmethod and staticmethod would have 
to change to support it.


>decorate(object, name="myfunc")
>
>The obvious keywords are the name and the context's
>globals;

Actually, those are not the obvious keywords.  The function's name is an 
attribute of the function, so it's redundant.  For that matter, a 
function's globals are available as 'func_globals'.  It's the enclosing 
*local* scope that the function was defined in that's needed.  For a 
function defined at module level, the globals and locals are the same, but 
for functions defined in a class body, you need the class locals.  So, 
'locals' would be a more obvious keyword.


>  decorators should probably accept arbitrary
>keywords for forward-compatibility.

I'm not sure this is a good idea.  The only additional argument that anyone 
has proposed that makes sense is the local scope.  I can't imagine what 
kind of change to Python would result in there being anything else that one 
might want.  On the other hand, I *can* imagine accidentally calling a 
decorator (assuming __call__ is used) and passing it invalid keywords that 
are then ignored, silencing an otherwise useful error message.