Back out 5bd9db528aed (issue #18408). It caused unsolved buildbot failures.

Objects/object.c

@@ -443,14 +443,6 @@ PyObject_Repr(PyObject *v)
     if (Py_TYPE(v)->tp_repr == NULL)
         return PyUnicode_FromFormat("<%s object at %p>",
                                     v->ob_type->tp_name, v);
-
-#ifdef Py_DEBUG
-    /* PyObject_Repr() must not be called with an exception set,
-       because it may clear it (directly or indirectly) and so the
-       caller looses its exception */
-    assert(!PyErr_Occurred());
-#endif
-
     res = (*v->ob_type->tp_repr)(v);
     if (res == NULL)
         return NULL;
@@ -482,7 +474,6 @@ PyObject_Str(PyObject *v)
 #endif
     if (v == NULL)
         return PyUnicode_FromString("<NULL>");
-
     if (PyUnicode_CheckExact(v)) {
 #ifndef Py_DEBUG
         if (PyUnicode_READY(v) < 0)
@@ -494,13 +485,6 @@ PyObject_Str(PyObject *v)
     if (Py_TYPE(v)->tp_str == NULL)
         return PyObject_Repr(v);
 
-#ifdef Py_DEBUG
-    /* PyObject_Str() must not be called with an exception set,
-       because it may clear it (directly or indirectly) and so the
-       caller looses its exception */
-    assert(!PyErr_Occurred());
-#endif
-
     /* It is possible for a type to have a tp_str representation that loops
        infinitely. */
     if (Py_EnterRecursiveCall(" while getting the str of an object"))

Objects/typeobject.c

@@ -736,13 +736,6 @@ type_call(PyTypeObject *type, PyObject *args, PyObject *kwds)
         return NULL;
     }
 
-#ifdef Py_DEBUG
-    /* type_call() must not be called with an exception set,
-       because it may clear it (directly or indirectly) and so the
-       caller looses its exception */
-    assert(!PyErr_Occurred());
-#endif
-
     obj = type->tp_new(type, args, kwds);
     if (obj != NULL) {
         /* Ugly exception: when the call was type(something),