bpo-44800: unobtrusively rename _PyInterpreterFrame to _Py_frame #32024
Conversation
| @@ -0,0 +1,5 @@ | |||
| Renamed ``_PyInterpreterFrame`` as ``_Py_frame`` to emphasise its close | |||
| association with ``PyFrameObject`` (they're conceptually the same thing, but | |||
There was a problem hiding this comment.
What does "conceptually the same thing" mean?
They aren't the same thing. What is the concept that makes them the same?
There was a problem hiding this comment.
The same thing that makes it OK to pass both PyFrameObject and _PyInterpreterFrame structs to functions that have names starting with _PyFrame: they're Python code evaluation frames either way, but you may be working with the underlying data storage directly, or you may be working with the full refcounted Python object.
The difference between the two is mechanical (how their memory allocation is managed) rather than conceptual.
There was a problem hiding this comment.
Your concepts are just that, your concepts. They are highly subjective.
PyFrameObjects and _PyInterpreterFrame are different things. One is a reference counted heap object, the other a stack frame. They have to managed quite differently, to me that means they are "conceptually distinct".
|
I really don't see why you think Also, could you explain why the change to the name of the struct, and changes to the names of its fields must be in the same PR? They seem like independent changes to me. |
|
Yes, I find "Interpreter" misleading, and as I said on the Discourse thread, it was your own comment on the first bpo-44800 PR that made me understand why it was confusing me: “From the point of view of Python code, the frame object is the frame, not just a view of it.” When the names are I think the last part of your comment may have been aimed at the previous PR, as there aren't any struct field name changes in this one. |
|
If
To you. Not to me. |
|
The ship sailed on The problem Python 3.11 has created is that suddenly a lot of those However, the only differences between When the two C types are instead
The only thing getting in the way of that conventional coding style is the redundant "interpreter" adjective in the name of the underlying C struct. (As far as preferred adjectives go, my preferred one is "execution frame", hence the use of that in the first bpo-44800 PR that prompted your observation about there being no conceptual distinction between the two frame structs: "From the point of view of Python code, the frame object is the frame, not just a view of it". That's the observation that persuaded me that the best adjective to use here is no adjective at all, since |
|
@markshannon I'm willing to close this and make a replacement PR that just documents the status quo in pycore_frame.h, but I'd like a definitive rejection from you first, rather than getting the silent treatment again. Specifically, I'm looking for confirmation that you don't believe that it is in any way confusing to have the "interpreter" adjective solely in the struct name, when it's absent from the names of all the functions that manipulate the struct, from the name of the Python object that wraps the struct, and from most of the variables and struct fields that reference the struct. |
|
I've said I don't like this change. I'm not sure what the "silent treatment" is, apart from not repeating myself. You point out that some of the functions that take Renaming |
|
Renaming the private APIs is something I tried in a previous iteration of the proposal - it gets even messier than renaming the types and fields did. I'll switch to adding internal code level documentation of the status quo (including the requirement to be super careful with not keeping hold of pointers to interpreter frames beyond their known validity) |
|
Replacement PR that just documents the status quo: #32281 |
_PyInterpreterFrameto_Py_frameto help indicate that_Py_frameis an implementation optimisation for frame objects rather than a distinct concept
pycore_frame.hcovering future naming conventions,as well as deviations from those conventions for historical reasons
cframeas a variable name to justframehttps://bugs.python.org/issue44800