Yeah, I think PyInterpreterView is a fine name too. My worry with “block finalization” as a verb is that it’s going to be long and cumbersome to type (e.g., PyFinalizationGuard_BlockFinalizationFromCurrent). Would it be okay to use something like PyFinalizationGuard_FromCurrent instead?
Regarding PyFinalizationGuard vs PyInterpreterGuard, I slightly like the latter more in case we ever want to use guards to block other things in the interpreter as well, but I won’t care too much if we ultimately choose PyFinalizationGuard
“To block finalization is the core developer’s goal.”
“To write code is the core developer’s goal.”
I agree with @h-vetinari that English is weird, and I don’t think this discussion is productive. If you want to argue that only “block” is the verb and “finalization” is the object, fine, but our C API usually doesn’t contain any verbs in the prefix, nonetheless. (For example, we use PyList_Append, not PyAppend_List.)
It’s possible I misunderstood. I was reading “block” as a noun, as in a block of code. If it’s meant as a verb in this context, as in to stop something from happening, the corresponding noun phrase would be “finalization blocking”.
I hadn’t considered the noun meaning of “block”, so the unambiguous “Prevent” may be better.
With that switched, I was suggesting top level APIs like Py_PreventFinalization (current interpreter only), PyInterpreterView_PreventFinalization (accepts a view), and Py_AllowFinalization, omitting the FinalizationGuard part of the prefix for the “current interpreter” variants, since the verb phrases aren’t generic ones that need to be scoped to a particular kind of struct.
I read Py_PreventFinalization as blocking runtime finalization (i.e., Py_Finalize) rather than interpreter finalization (i.e., Py_EndInterpreter), because we usually reserve the Py_ prefix for high-level runtime operations. I think we want some sort of prefix to disambiguate that.
And we’d use phrasing like “guarding against interpreter shutdown” in the documentation.
I was hesitant to add the new noun without a more explicit qualifier than “interpreter” (since there’s nothing about “guard” that specifically indicates “prevents shutdown”), but maybe “not a lock and not a counted reference” is sufficient “at a glance” info, with the docs filling in the rest.
And trying to get the full phrase “interpreter finalization guard” directly into the name is definitely too verbose.
Since I agree that shortening it to “finalization guard” would be ambiguous about whether it’s a runtime or per-interpreter API, that leaves me also agreeing that “interpreter guard” is the best option out of the various names we’ve considered.
