Brandt Bucher <brandtbuc...@gmail.com> added the comment:
I'm going to take a stab at making this work today. The idea is to do something like this when setting a new frame: - Clear and pop tstate->cframe->current_frame and all of its linked predecessors. - These should all belong to the same CFrame, right? - Push copies of the new InterpreterFrame and all of its predecessors (bottom to top, of course), and update all of the PyFrameObjects to point to the new copies. - I'm just going to assert(f->f_owns_frame) before copying each of these (and set it to 0, after). I don't think it could ever be valid to stick a new copy of an active frame onto the top of the stack? - Set tstate->cframe->current_frame to the new, top InterpreterFrame. - If my understanding of the new CFrame mechanics is correct, I don't think we'd need to touch the C stack at all? Maybe I'm missing something, though... if we do need to change the size of the C stack, this whole thing becomes a *lot* more painful. Anyone see any obvious flaws here? I'm new to a lot of this code, so any guidance would be appreciated. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue46090> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
