I'm not sure we can simply remove this from the C API, as it is unfortunately exposed via Python.h:

$ echo '#include "Python.h"' | gcc -E $(./python.exe ./python-config.py --includes) - | grep _PyErr_ChainExceptions
__attribute__ ((visibility ("default"))) void _PyErr_ChainExceptions(PyObject *, PyObject *, PyObject *);
__attribute__ ((visibility ("default"))) void _PyErr_ChainExceptions1(PyObject *);

cc. @encukou

When you're done making the requested changes, leave the comment: I have made the requested changes; please review again.

I'm not sure we can simply remove this from the C API, as it is unfortunately exposed via Python.h:

It is prefixed with an underscore so we can, in theory, remove it. But we will need to document how to upgrade to 3.12.
We could leave _PyErr_ChainExceptions in as a deprecated shim that calls _PyErr_ChainExceptions1 for a couple of releases, if we think removing it will cause breakages.

We could leave _PyErr_ChainExceptions in as a deprecated shim that calls _PyErr_ChainExceptions1 for a couple of releases

Currently it normalises the exception so just calling _PyErr_ChainExceptions1 with the second arg would be a change in semantics.

Since it is exposed via Python.h, someone is bound to be using it, so we cannot just remove it. I'd say we mark it as deprecated using the Py_DEPRECATED macro. There's practically no maintenance overhead in keeping it around.

BTW, we should consider unexposing the new API (_PyErr_ChainExceptions1) by moving it to Include/internal before 3.12 is frozen.

I searched on GitHub and found quite a few usages. So I agree with just deprecating it for now.

Not sure it's reasonable to not expose the alternative though, given people are using it.

Not sure it's reasonable to not expose the alternative though, given people are using it.

Since people are using it, we should consider dropping the underscore, IMO.