Greg Turner added the comment: Also:
In types.prepare_class, here is what currently happens: we let x be, in order of preference: (a) the explicitly given type if, one is given, else (b) type(bases[0]), if it exists, else (c) type and then, if isinstance(x, type), we run _calculate_bases. In python 2, I think something like this really does happen, although, perhaps "isinstance(x, type)" should have been "issubclass(x, type)" to correctly capture how python 2 does it. In particular, I think we can stick a Callable in there as bases[0], and then any old crazy list of objects as base classes, and it will call our Callable, although if we don't do something about our crazy base classes, it will still break later (something like that... I don't remember exactly, except that the first base is definitely special somehow). But in python 3, if I'm reading the C code correctly, I don't think the first base class receives any "special" handling, and the cpython-equivalent to _calculate_bases /always/ happens, suggesting that any non-descending-from-type metaclass is expected to have removed itself from the picture before type_new is invoked. So maybe more minor re-factoring is needed to get it all straightened out. My brain is kind of fried from looking at it, I'll try again later. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22968> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
