[Python-ideas] make __closure__ writable
yselivanov.ml at gmail.com
Tue Mar 20 14:06:18 CET 2012
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:
orig_func = func
func = func.__wrapped__
# patch func.__code__ and func.__closure__
return orig_func # no need to wrap anything
def wrapper(*args, **kwargs):
# some code
return func(*args, **kwargs)
# 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.
> Python-ideas mailing list
> Python-ideas at python.org
More information about the Python-ideas