Issue #26906: Resolving special methods of uninitialized type now causes

implicit initialization of the type instead of a fail.

diff --git a/Misc/NEWS b/Misc/NEWS
index ff55afe99f8d747f5bb5a5b6f8dc2f4f0db08f85..872e013fb125b2e4cadad79f68ca7478b885cb8b 100644 (file)
--- a/Misc/NEWS
+++ b/Misc/NEWS
@@ -10,6 +10,9 @@ What's New in Python 2.7.13?
 Core and Builtins
 -----------------
 
+- Issue #26906: Resolving special methods of uninitialized type now causes
+  implicit initialization of the type instead of a fail.
+
 - Issue #18287: PyType_Ready() now checks that tp_name is not NULL.
   Original patch by Niklas Koep.
 

diff --git a/Objects/typeobject.c b/Objects/typeobject.c
index f6d46632add51d04be296c15f76e92c415fa60fa..932f9e994a50c0d21ea8d41823be24b57f090314 100644 (file)
--- a/Objects/typeobject.c
+++ b/Objects/typeobject.c
@@ -2545,11 +2545,25 @@ _PyType_Lookup(PyTypeObject *type, PyObject *name)
     /* Look in tp_dict of types in MRO */
     mro = type->tp_mro;
 
-    /* If mro is NULL, the type is either not yet initialized
-       by PyType_Ready(), or already cleared by type_clear().
-       Either way the safest thing to do is to return NULL. */
-    if (mro == NULL)
-        return NULL;
+    if (mro == NULL) {
+        if ((type->tp_flags & Py_TPFLAGS_READYING) == 0 &&
+            PyType_Ready(type) < 0) {
+            /* It's not ideal to clear the error condition,
+               but this function is documented as not setting
+               an exception, and I don't want to change that.
+               When PyType_Ready() can't proceed, it won't
+               set the "ready" flag, so future attempts to ready
+               the same type will call it again -- hopefully
+               in a context that propagates the exception out.
+            */
+            PyErr_Clear();
+            return NULL;
+        }
+        mro = type->tp_mro;
+        if (mro == NULL) {
+            return NULL;
+        }
+    }
 
     res = NULL;
     assert(PyTuple_Check(mro));