Author ncoghlan
Recipients Mark.Shannon, ncoghlan, pablogsal
Date 2021-08-11.10:25:50
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1628677550.27.0.0983795222608.issue44800@roundup.psfhosted.org>
In-reply-to
Content
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.
History
Date User Action Args
2021-08-11 10:25:50ncoghlansetrecipients: + ncoghlan, Mark.Shannon, pablogsal
2021-08-11 10:25:50ncoghlansetmessageid: <1628677550.27.0.0983795222608.issue44800@roundup.psfhosted.org>
2021-08-11 10:25:50ncoghlanlinkissue44800 messages
2021-08-11 10:25:50ncoghlancreate