The `_PyFrame_Init()` and `PyByteArray_Init()` functions are called in these two locations in the `_Py_InitializeCore()` function:

	https://github.com/python/cpython/blob/master/Python/pylifecycle.c#L693-L694
	https://github.com/python/cpython/blob/master/Python/pylifecycle.c#L699-L700

But their function definitions appear to do nothing:

	https://github.com/python/cpython/blob/master/Objects/frameobject.c#L555-L561
	https://github.com/python/cpython/blob/master/Objects/bytearrayobject.c#L24-L28

I can understand leaving the functions in the source for backwards-compatibility, but why are they still being called in `_Py_InitializeCore()`? Seems like it just adds noise for those new to the cpython internals (I certainly found it confusing myself).

Ned Batchelder recommended possibly making a change:

	https://mail.python.org/pipermail/python-list/2018-March/731402.html

(Bringing my response from core-mentorship over to the main tracker)

These APIs are exposed to embedding applications via the pylifecycle header: https://github.com/python/cpython/blob/master/Include/pylifecycle.h#L143

While we technically *could* deprecate & remove them (since we're not currently using them for anything), the current cost/benefit assessment is that it isn't worth the API churn (even for the underscore prefixed _PyFrame_Init API) when it's relatively cheap to keep them around as no-ops.

Given that they exist in the code base in order to continue exporting the symbols though, future maintainers are entitled to expect that we'll keep calling them in the appropriate places, such that if anyone *does* add code to them in the future, that code will "just work".

Future maintainers of what exactly can expect these functions to be called? CPython? If we need to do initialization of frameobject.c later, we can simply add _PyFrame_Init back. We certainly don't support ELF-interposition of _PyFrame_Init as an API.

Historically, we've been sloppy about putting private and public APIs in the same header files. But the leading underscore still means private; such APIs serve at our pleasure.

Yeah, dropping _PyFrame_Init/Fini for 3.8+ would make sense.

It's PyByteArray_Init/Fini that probably aren't worth the hassle of removing, since the lack of a leading underscore means they'd need to go through a deprecation cycle.

ince I originated this issue and I think I understand the concerns, I figured I could speed up the back and forth in this thread by opening this new PR which removes the `_PyFrame_Init()` function. I couldn't find any `_PyFrame_Fini()` function in the source so maybe you two are confused and there wasn't a corresponding Fini function? (I presume the more likely scenario is that I am the one who is confused so feel free to correct that confusion in that case. :) )

New changeset 7023644e0c310a3006c984318c2c111c468735b4 by Benjamin Peterson (Thomas Nyberg) in branch 'master':
closes bpo-32980 Remove _PyFrame_Init (GH-5965)
https://github.com/python/cpython/commit/7023644e0c310a3006c984318c2c111c468735b4