I think it is worth to test also the case when the argument is a tuple and when the argument is a KeyError instance. I think this was the reason of introducing _PyErr_SetKeyError() instead of simply calling PyErr_SetObject().

Ok, I added tests on a tuple and a KeyError.

I think this was the reason of introducing _PyErr_SetKeyError() instead of simply calling PyErr_SetObject().

Ah right, PyErr_SetObject(exc_type, value) has an unsual API: if value is a tuple, it unpacks arguments by calling exc_type(*value). Otherwise, it calls exc_type(value).

And if the value is already an instance of the specified exception type, it just uses it.

This comment is outdated, because the code no longer explicitly wraps the key in a tuple. But it has roughtly the same effect, the reasons why it does not simply use PyErr_SetObject() is still valid. If we keep the current code, we need other wording here.

I wonder if partial reversion of aa36f83 will fix the issue. Would it have performance impact? This is just a curiosity, not suggestion.

I updated the comment by removing the part about wrapping into a tuple.

I wonder if partial reversion of aa36f83 will fix the issue.

The old implementation can be called with an exception set:

void
_PyErr_SetKeyError(PyObject *arg)
{
    PyThreadState *tstate = _PyThreadState_GET();
    PyObject *tup = PyTuple_Pack(1, arg);
    if (!tup) {
        /* caller will expect error to be set anyway */
        return;
    }
    _PyErr_SetObject(tstate, PyExc_KeyError, tup);
    Py_DECREF(tup);
}

Would it have performance impact? This is just a curiosity, not suggestion.

According to my comment, I rewrote _PyErr_SetKeyError() to be able to reuse the faster BaseException_vectorcall(). I don't know if it has a significant impact on performance. This vectorcall function has to create a tuple of arguments using _PyTuple_FromArray(args, PyVectorcall_NARGS(nargsf)).

And if the value is already an instance of the specified exception type, it just uses it.