[Python-Dev] PEP 318 - check for consensus (original) (raw)

Guido van Rossum guido at python.org
Wed Apr 14 12:30:30 EDT 2004

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/)

More information about the Python-Dev mailing list