mirror of
https://github.com/python/cpython.git
synced 2025-08-03 16:39:00 +00:00
Issue #26906: Resolving special methods of uninitialized type now causes
implicit initialization of the type instead of a fail.
This commit is contained in:
commit
56588b7055
2 changed files with 22 additions and 5 deletions
|
@ -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)
|
||||
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
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue