From: Serhiy Storchaka Date: Sat, 8 Oct 2016 09:24:09 +0000 (+0300) Subject: Issue #26906: Resolving special methods of uninitialized type now causes X-Git-Tag: v2.7.13rc1~83 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=61dd7ff0735936b77071a90151faccb9eb8ca16d;p=python 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 ff55afe99f..872e013fb1 100644 --- 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 f6d46632ad..932f9e994a 100644 --- 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));