Mirror
/
cpython
mirror of https://github.com/python/cpython
4
1
Fork 0
Code Issues Releases Wiki Activity

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

implicit initialization of the type instead of a fail.
This commit is contained in:
Serhiy Storchaka 2016-10-08 12:26:25 +03:00
parent 2b801456fb 8ef34600c7
commit 56588b7055
2 changed files with 22 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
Misc/NEWS
View File

@ -10,6 +10,9 @@ What's New in Python 3.6.0 beta 2
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.

22
Objects/typeobject.c
View File

@ -2914,11 +2914,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)
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