Almost every time I use decorators, I find myself wishing I had access to the local namespace of the context from which the decorator is executed. In practice, decorator is being applied to a method, so the namespace in question would be the dictionary of the class being created.
Similarly, before decorators were around, I often found myself lamenting the fact that a class is not created until after it's scope is completed, since this makes certain kinds of metaprogramming more difficult. But after digging deeper, I realized why it is the way it is, so I don't complain about that. But it would have been a simple thing to add an argument 'locals' to the decorator specification. It's somewhat more difficult to add that now because of compatibility issues, but perhaps there is a way to get the same effect. I can work around all of this by making my decorators just store data to be processed by a metaclass, but that solution is less elegant. Also, it has the slight disadvantage of requiring the use of a metaclass which would otherwise not be necessary. I prefer to save metaclass implementation as a last resort for various reasons (e.g. there does not seem to be a good way to use multiple metaclasses in a class hierarchy, and more generally you can't stack them on top of each other (you can only have one metaclass per class)). Thoughts? - Ken -- http://mail.python.org/mailman/listinfo/python-list
