New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
make function __closure__ writable #58577
Comments
__code__ and __closure__ are designed to work together. There is no point in allowing to completely substitute the __code__ object, but protecting the __closure__. |
Updated patch as per Andrew's code review. Thank you. |
Please update the doc also. I think changing from 'Read-only' to 'Writable' in Doc/reference/datamodel.rst is enough. |
Updated in writable_closure_03.patch. Thanks. |
Updated patch per Benjamin's review. See writable_closure_04.patch. |
Another use case for a writeable __closure__ attribute is to make it possible to manually break reference cycles: |
Shouldn't test___closure__() also test what happens when the closure is replaced with None, or a tuple which is too long or too short or contains non-cell objects? All of these things seem to be checked when you create a new function using types.FunctionType: >>> h = types.FunctionType(g.__code__, g.__globals__, "h", g.__defaults__, None)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: arg 5 (closure) must be tuple
>>> h = types.FunctionType(g.__code__, g.__globals__, "h", g.__defaults__, ())
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: g requires closure of length 2, not 0
>>> h = types.FunctionType(g.__code__, g.__globals__, "h", g.__defaults__, (1,2))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: arg 5 (closure) expected cell, found int I think the setter should make similar checks. Maybe there is C code which assumes "broken" closures never happen. |
The patch causes crashes. If I define def cell(o):
def f(): o
return f.__closure__[0]
def f():
a = 1
b = 2
def g():
return a + b
return g
g = f() then I find g.__closure__ = None; g() -> crash
g.__closure__ = (cell(3),); g() -> crash
g.__closure__ = (1, 2); g() -> SystemError *
g.__closure__ = (cell(3), cell(4), cell(5)); g() -> returns 7
|
Yes, that's known. First, we need to check, that we can only write tuple of cell objects or None in __closure__ (that's easy to add). Secondly, perhaps, we can check __closure__ correctness each time we start evaluating a code object. The latter would offer us better stability, but may also introduce some slowdowns -- need to find some time to implement and benchmark this. |
Version of patch which checks invariants in the setter and adds tests. |
sbt, looks good for me. |
Any updates on this? I'm trying to implement hot module reloading using code from IPython, which tries to modify __closure__ in place. It fails silently and doesn't work, but indeed would be nice to have. |
This still seems like a reasonable enhancement, but would presumably need updates to apply against the 3.7 development branch. |
Thinking about the interaction between this idea and https://bugs.python.org/issue30744 made me realise that there's a subtlety here that would probably need to be spelled out more clearly in the docs for __closure__ than it is for __code__: any changes made to a function object (whether it's a synchronous function, a generator, or a coroutine) will only affect *future* function invocations, as execution frames capture references to both the code object and all the closure cells when they're created. (Thought prompted by asking myself "What would happen to existing generator-iterators if you rebound the closure on the generator function?". The answer is "Nothing", but I figure if I had to think about it, that answer likely isn't going to be obvious to folks that are less familiar with how the eval loop works in practice) |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
Linked PRs
The text was updated successfully, but these errors were encountered: