This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

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?
History
Date User Action Args
2013-05-14 11:41:17kristjan.jonssonsetrecipients: + kristjan.jonsson, gvanrossum, fdrake, amaury.forgeotdarc, ncoghlan, pitrou, daniel.urban, pconnell, isoschiz
2013-05-14 11:41:17kristjan.jonssonsetmessageid: <1368531677.88.0.962646088346.issue17950@psf.upfronthosting.co.za>
2013-05-14 11:41:17kristjan.jonssonlinkissue17950 messages
2013-05-14 11:41:17kristjan.jonssoncreate