cpython: d24f1467a297 (original) (raw)
Mercurial > cpython
changeset 104368:d24f1467a297
Issue #26906: Resolving special methods of uninitialized type now causes implicit initialization of the type instead of a fail. [#26906]
Serhiy Storchaka storchaka@gmail.com | |
---|---|
date | Sat, 08 Oct 2016 12:28:25 +0300 |
parents | 696851f38c93(current diff)888a26fac9d2(diff) |
children | 085944763f3a |
files | Misc/NEWS |
diffstat | 2 files changed, 22 insertions(+), 5 deletions(-)[+] [-] Misc/NEWS 3 Objects/typeobject.c 24 |
line wrap: on
line diff
--- a/Misc/NEWS +++ b/Misc/NEWS @@ -10,6 +10,9 @@ What's New in Python 3.7.0 alpha 1 Core and Builtins ----------------- +- Issue #26906: Resolving special methods of uninitialized type now causes
--- a/Objects/typeobject.c +++ b/Objects/typeobject.c @@ -2914,11 +2914,25 @@ PyObject / 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().[](#l2.8)
Either way the safest thing to do is to return NULL. */[](#l2.9)
- if (mro == NULL)
return NULL;[](#l2.11)
- if (mro == NULL) {
if ((type->tp_flags & Py_TPFLAGS_READYING) == 0 &&[](#l2.13)
PyType_Ready(type) < 0) {[](#l2.14)
/* It's not ideal to clear the error condition,[](#l2.15)
but this function is documented as not setting[](#l2.16)
an exception, and I don't want to change that.[](#l2.17)
When PyType_Ready() can't proceed, it won't[](#l2.18)
set the "ready" flag, so future attempts to ready[](#l2.19)
the same type will call it again -- hopefully[](#l2.20)
in a context that propagates the exception out.[](#l2.21)
*/[](#l2.22)
PyErr_Clear();[](#l2.23)
return NULL;[](#l2.24)
}[](#l2.25)
mro = type->tp_mro;[](#l2.26)
if (mro == NULL) {[](#l2.27)
return NULL;[](#l2.28)
}[](#l2.29)
- }
res = NULL; /* keep a strong reference to mro because type->tp_mro can be replaced