I did provide such example earlier in this thread. I'm copying and pasting it to this mail. Please read the example carefully, as it explains why returning new types.FunctionType() is not enough. ---- Yes, your approach will work if your decorator is the only one applied. But, as I said, if you have many of them (see below), you can't just return a new function out of your decorator, you need to change the underlying "in-place". Consider the following: def modifier(func): orig_func = func while func.__wrapped__: func = func.__wrapped__ # patch func.__code__ and func.__closure__ return orig_func # no need to wrap anything def some_decorator(func): def wrapper(*args, **kwargs): # some code return func(*args, **kwargs) functools.wraps(wrapper, func) return wrapper @modifier @some_decorator def foo(): # this code needs to be verified/augmented/etc So, in the above snippet, if you don't want to discard the @some_decorator by returning a new function object, you need to modify the 'foo' from the @modifier. In a complex framework, where you can't guarantee that your magic decorator will always be called first, rewriting the __closure__ attribute is the only way. Again, since the __code__ attribute is modifiable, and __closure__ works in tight conjunction with it, I see no point in protecting it. On 2012-03-20, at 5:34 AM, Mark Shannon wrote:
Yury Selivanov wrote:
I've created an issue: http://bugs.python.org/issue14369
I think that creating an issue may be premature, given that you have had no positive feedback on the idea.
I still think making __closure__ mutable is unnecessary. If you insist that it is it, then please provide an example which would work with your proposed change, but cannot be made to work using types.FunctionType() to create a new closure.
Cheers, Mark. _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas