(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. :) )
