[issue44800] Code readability: rename interpreter frames to execution frames

[Nick Coghlan]

Nick Coghlan  added the comment:

Mark raised some valid concerns with the proposed naming convention over on the 
PR:

* the proposed names make it sound like there are genuinely two kinds of frame, 
when the actual relationship is between a frame's data storage and a Python 
object providing an interface to that storage
* _PyExecFrame looks like an actual Python type name, so we probably want 
something more like "Py_buffer" (where the lowercase name is intended to 
indicate that the struct isn't a full Python type)

Mark offered "activation record" as a possible name, but I'm going to see how 
"_Py_framedata" looks first (with "fdata" as the abbreviated form, since "fd" 
is so frequently used to mean "file descriptor")

I'm also going to see how the PR looks if both the frame and frame data struct 
keep their existing field prefixes - it may be that changing variable names 
will be enough to avoid ambiguity, in which case leaving the field names alone 
genuinely reduces code churn.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44800] Code readability: rename interpreter frames to execution frames

[Nick Coghlan]

Nick Coghlan  added the comment:

PR for this proposed refactoring is now up, with a review requested from Mark: 
https://github.com/python/cpython/pull/27525/

The PR mostly follows what I originally posted, except that I went with 
_Py_execution_frame and _PyExecFrame for the struct and typedef names, since 
these are present in a public header.

The outdated GDB hooks I found were in the gdbinit example file, rather than 
the actual libpython.py file that test_gdb covers. I suspect the gdbinit 
example will need further adjustments to actually work with Python 3.11, so 
rather than fully updating the implementation dependent pieces, I just added a 
comment suggesting it be checked after the interpreter optimisation development 
for 3.11 settles down.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44800] Code readability: rename interpreter frames to execution frames

[Nick Coghlan]

Change by Nick Coghlan :


--
keywords: +patch
pull_requests: +26040
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/27525

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44800] Code readability: rename interpreter frames to execution frames

[Nick Coghlan]

Nick Coghlan  added the comment:

As a side effect of working on this, I noticed some changes that are needed to 
adapt the GDB integration hooks to the new frame state layout.

--
nosy: +pablogsal

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44800] Code readability: rename interpreter frames to execution frames

[Nick Coghlan]

Change by Nick Coghlan :


--
assignee:  -> ncoghlan

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44800] Code readability: rename interpreter frames to execution frames

[Nick Coghlan]

Change by Nick Coghlan :


--
dependencies: +Create frame objects lazily when needed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44800] Code readability: rename interpreter frames to execution frames

[Nick Coghlan]

New submission from Nick Coghlan :

When merging the bpo-44590 changes into my PEP 558 implementation branch, I 
found it very hard to follow when the code was referring to the new interpreter 
frames rather than the existing Python frame objects that were historically 
used for both execution and introspection.

The "interpreter frame" name was also a little confusing, since the 
introspection frames are still associated with a specific interpreter, they're 
just not required for code execution anymore, only for code introspection APIs 
that call for a full Python object.

So, inspired by the "gi_xframe" (etc) attributes added in 
https://github.com/python/cpython/pull/27077, I'm proposing the following 
internal refactoring:

* Rename "pycore_frame.h" to "pycore_xframe.h"
* Rename the _interpreter_frame struct to _execution_frame
* Rename the type from InterpreterFrame to ExecFrame
* Use "xf_" rather than "f_" as the struct field prefix on execution frames
* Use "xframe" and "xf" rather than "frame" and "f" for execution frame 
variables
* Consistently use _PyExecFrame as the access function prefix, rather than a 
confusing mixture of _PyFrame and _PyInterpreterFrame
* Rename _PyThreadState_PushFrame to _PyThreadState_PushExecFrame
* Rename _PyThreadState_PopFrame to _PyThreadState_PopExecFrame

--
messages: 398675
nosy: Mark.Shannon, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Code readability: rename interpreter frames to execution frames
type: enhancement
versions: Python 3.11

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com