Skip to content
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

closure Frame initialization uses wrong outer frame #17

Open
matthiaskramm opened this issue Feb 24, 2015 · 2 comments
Open

closure Frame initialization uses wrong outer frame #17

matthiaskramm opened this issue Feb 24, 2015 · 2 comments

Comments

@matthiaskramm
Copy link

The current version of byterun accesses cellvars through the frame the closure is executing under, instead of the frame it was defined in. The following code illustrates the problem:

def f():
x = ["foo"]
def inner():
x[0] = "bar"
return inner

def g(funcptr):
x = 5
def inner():
return x
y = funcptr()

g(f())

AssertionError: "'int' object does not support item assignment" != 'None'

@arthurp
Copy link

arthurp commented Mar 2, 2015

I thought I fixed this in my branch. Could you check against https://github.com/google/byterun ? I know I did some work on closure capture.

It never got merged because I never had the time to clean the code to get it accepted by nedbat.

@matthiaskramm
Copy link
Author

Arthur: I'm afraid it's broken in your branch as well - both use f_back to link cells to their function, instead of using the closure parameter of pyobj.Function. The f_back trick is a surprisingly good approximation, though, and all of the existing test cases work with it. But the above is still broken.

darius added a commit to darius/byterun that referenced this issue Feb 17, 2016
darius added a commit to darius/byterun that referenced this issue Feb 17, 2016
…ixes nedbat#17. (I haven't checked this code against the CPython code, but at least we're more correct than before, by the tests.
rocky pushed a commit to rocky/x-python that referenced this issue Jun 4, 2020
See nedbat#17

Thanks to @matthiaskramm noting and reporting the problem, and @darius
for providing a test case.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants