Proposal: rename _PyInterpreterFrame struct as _Py_framedata

Core Development
2

Note: this follow up post is just some additional background info on why I find the status quo in the code base problematic, even though the current state was reached for sound reasons (as discussed in Core developer rules of thumb (incl. "What needs a PEP"?) the PRs introducing the frame data storage split intentionally minimised any name changes so that reviewers could focus on the functional changes. Hence struct fields following the naming conventions of their origins, local variables and function parameters keeping their old names even as their data types changed, etc).

When developing large C code bases, there are some useful rules of thumb that can be followed to help readers correctly orient themselves in the code base, even in the presence of 100+ line functions where variable declarations may be a long way from the code that uses those variables.

The relevant ones for this particular discussion that CPython has traditionally followed are:

  • use consistent naming conventions for local variables of a particular type (so the use of the conventional name provides a strong hint as to the type being used)
  • use dedicated prefixes for fields of particular structs (so use of the struct can be readily identified in the code even when a non-conventional variable name is used)
  • use consistent and distinct prefixes for functions and macros that are designed to work with particular data structures (the “C structs-as-objects” coding style)

Taking the “low impact” approach to the introduction of the separate frame data structs has resulted in a situation where all three of those techniques are no longer being applied:

  • frame and f may be either a full frame object or a frame data struct, it depends on whether the code is part of the optimised eval loop or not
  • some of the frame data struct fields still have the f_* prefix if they were originally defined on full frame objects
  • Many _PyFrame_ functions now actually work on the frame data structs rather than on full frame objects

The WIP PR attempts to at least restore the first two conventions where these structures are concerned. As noted in the initial post, previous iterations also changed the function names, but I decided in the latest iteration that there was enough ambiguity reduction without also making that change.

2 Likes