bpo-46836: Rename InterpreterFrame to _PyInterpreterFrame

[vstinner]

Rename also struct _interpreter_frame to struct _PyInterpreterFrame.

Reduce risk of name conflicts if a project includes pycore_frame.h.

https://bugs.python.org/issue46836

[vstinner]

While most people should not use the internal C API, there are some legit use cases to use pycore_frame.h: mostly debuggers and profilers.

[vstinner]

cc @markshannon @brandtbucher

[markshannon]

Please stop renaming things without any review.

[markshannon]

If any debuggers or profilers were including these headers, then you have just broken them.

[vstinner]

If any debuggers or profilers were including these headers, then you have just broken them.

Python 3.11.0 final is not released yet. I prefer to rename it now.

[vstinner]

The problem of the InterpreterFrame type is that it's used by the PyInterpreterState.eval_frame callback API which is somehow public: https://www.python.org/dev/peps/pep-0523/

Technically, PyInterpreterState is part of the internal C API. So I would say that it's an internal C API. But well, people use it for debuggers. So it's better to make this "internal" API comply with Python C code code: prefix symbols with Py or _Py.

See also this private API (private, not internal ;-)):

typedef PyObject* (*_PyFrameEvalFunction)(PyThreadState *tstate, struct _PyInterpreterFrame *, int);

PyAPI_FUNC(_PyFrameEvalFunction) _PyInterpreterState_GetEvalFrameFunc(
    PyInterpreterState *interp);
PyAPI_FUNC(void) _PyInterpreterState_SetEvalFrameFunc(
    PyInterpreterState *interp,
    _PyFrameEvalFunction eval_frame);

[vstinner]

Moreover, my short term plan to update Cython and gevent for https://bugs.python.org/issue46836 (to port them to Python 3.11 with opaque PyFrameObject type) is to make them use the internal C API pycore_frame.h. I would prefer to not have do that, but https://bugs.python.org/issue40421 is not fixed yet: there are not enough getter and setter functions for PyFrameObject.

[vstinner]

If any debuggers or profilers were including these headers, then you have just broken them.

That's fine. There is no backward compatibility on the internal C API (nor on the private C API).

[markshannon]

That is true, but it makes our life more difficult if those tools are constantly broken, as it can hide real problems.
So, please be a bit more cautious in future. Thanks.

[vstinner]

That is true, but it makes our life more difficult if those tools are constantly broken, as it can hide real problems.
So, please be a bit more cautious in future. Thanks.

Ok, gotcha.