I assume someone is going to review each of these to determine whether they're in the right places? (e.g. the public docs should not be using an internal macro)

If we really do want to update every single use, well, that's why we have the original macro. We should just change it.

My understanding of immortal objects is that we'd carefully opt-in certain types, and not do a global find/replace like this. But possibly the design has changed in a way I haven't kept up with.

At the very least, if it belongs in public docs, make it a public macro. And if it applies literally everywhere, just modify the existing macro.

carefully opt-in certain types, and not do a global find/replace like this

@zooba We are opting in all static objects as they live throughout the entire execution of the runtime!

Like Steve, I do wonder, why not change the macro instead of 150+ files?

@zooba @gvanrossum the main goal was to not change the expectations of the public C-API of PyObject_HEAD_INIT and PyVarObject_HEAD_INIT. I think that it should use the immortal value by default but given that this is a public C-API, the goal was to minimize the number of 'disruptive' changes (though it should still be compatible backwards compatible).

All that said, the solution of using Py_BUILD_CORE works really nicely so I'll incorporate that in the main PR and close this PR. Whether we change the default to be immortal or not, I'll leave that to a future discussion (unless anyone has strong opinions otherwise 🙂 )