Nathaniel Smith added the comment:

Some thoughts based on discussion with Armin in #pypy:

It turns out if you simply delete the LocalsToFast and FastToLocals calls in 
call_trampoline, then the test suite still passes. I'm pretty sure that pdb 
relies on this as a way to set local variables, though, so I think this is 
probably more of a bug in the test suite than anything else.

In some ways, it seems like the most attractive fix to this would be to have 
the Python-level locals() and frame.f_locals return a dict proxy object whose 
__setitem__ writes any mutations back to both the fast array and the real 
frame->f_locals object, so that LocalsToFast becomes unnecessary. As Armin 
points out, though, that would definitely be a semantic change: there may be 
code out there that relies on locals() returning a dict – technically it 
doesn't have to return a dict even now, but it almost always does – or that 
assumes it can mutate the locals() array without that affecting the function. I 
think this would arguably be a *good* thing; it would make the behavior of 
locals() and f_locals much less confusing in general. But he's right that it's 
something we can only consider for 3.7.

The only more-compatible version I can think of is: before calling the trace 
function, do FastToLocals, and also make a "shadow copy" of all the cellvars 
and freevars. Then after the trace function returns, when copying back from 
LocalsToFast, check against these shadow copies, and only write back 
cellvars/freevars that the trace function actually modified (where by modified 
we mean 'old is not new', just a pointer comparison). Since most functions have 
no cellvars or freevars, and since we would only need to do this when there's a 
Python-level trace function active, this shouldn't add much overhead. And it 
should be compatible enough to backport even to 2.7, I think.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30744>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to