> 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4