Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR seems to be 3 PRs in one:
1 Fixes to gdbinit
2 Changing the name of InterpreterFrame to _PyExecFrame
3 Adorning many fields with "x"

1. Thanks for the fix. Would you put the fixes to gdbinit in its own PR, please.
   Do you have any ideas on how to add tests for this, to avoid anyone (probably me 🙂) breaking it again?

2. Naming, the first hard problem in computer science! I think "Exec" doesn't really convey any more information than "Interpreter". Also, there should be probably be no "_Py" prefix, as that weakly implies that _PyExecFrame is a PyObject, which it is not.
   How about the old fashioned term "activation record"? The term "frame" is now so overloaded.

3. I left the original names mostly unchanged for a reason. If the value of the attribute, e.g. f_lasti is unchanged, then it makes porting code easier if the name is unchanged. Which is why f_back becomes previous, because the value has changed. I'm sure there are some clarifications that could be made here, but could they go in a PR after we have decided on a name?

Finally, I'd avoid the term "introspection frame". From the point of view of Python code, the frame object is the frame, not just a view of it. Maybe phrase any comments in terms of the InterpreterFrame/_PyExecFrame/ActivationRecord being a storage optimization of the frame?

I believe that @pablogsal has been looking into writing up the way that the call stack now works, so he might have some thoughts on this.