Message189207
| Author |
kristjan.jonsson |
| Recipients |
amaury.forgeotdarc, daniel.urban, fdrake, gvanrossum, isoschiz, kristjan.jonsson, ncoghlan, pconnell, pitrou |
| Date |
2013年05月14日.11:41:17 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1368531677.88.0.962646088346.issue17950@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
Thanks Guido.
The current patch provides the property you ask for. I will see if I can make the "fiddling" of the internal tuple less magical.
I have one other question for you: The standard "mro" puts the class in the 0th position.
But apparently, there is a mechanism for a "custom" mro, by calling an mro() function on the type (as far as I understand).
However, the order of objects in the returned tuple is not verified, only the types of the objects therein (this is in mro_internal())
Yet there is code that manually skips the 0th element, e.g. this code
/* Initialize tp_dict properly */
bases = type->tp_mro;
assert(bases != NULL);
assert(PyTuple_Check(bases));
n = PyTuple_GET_SIZE(bases);
for (i = 1; i < n; i++) {
PyObject *b = PyTuple_GET_ITEM(bases, i);
if (PyType_Check(b))
inherit_slots(type, (PyTypeObject *)b);
}
(from PyType_Ready())
I'm not familiar with the mro() function. What kind of black magic is it supposed to provide? And how can we make sure that its free-form return value is reconciled with the 1-based loop above? |
|