From 8ef34600c7dfa2608fe1ad235cf5fc36392fe469 Mon Sep 17 00:00:00 2001 From: Serhiy Storchaka Date: Sat, 8 Oct 2016 12:24:09 +0300 Subject: Issue #26906: Resolving special methods of uninitialized type now causes implicit initialization of the type instead of a fail. --- Misc/NEWS | 3 +++ Objects/typeobject.c | 24 +++++++++++++++++++----- 2 files changed, 22 insertions(+), 5 deletions(-) diff --git a/Misc/NEWS b/Misc/NEWS index 1b1c9d6..9168197 100644 --- a/Misc/NEWS +++ b/Misc/NEWS @@ -10,6 +10,9 @@ Release date: TBA 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 cbffecd..e9384ab 100644 --- a/Objects/typeobject.c +++ b/Objects/typeobject.c @@ -2869,11 +2869,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; /* keep a strong reference to mro because type->tp_mro can be replaced -- cgit v0.12