If a type's tp_base has not been initialized yet, PyType_Ready calls 
itself for tp_base.  However, it doesn't do the same for members of 
tp_bases.  The inheritance determinations assume that all bases are 
ready, in particular that tp_mro is not null.

I believe that's because the bases are supposed to be ready at the time
a subclass is created.

If that were the case, it wouldn't need to call PyType_Ready for 
tp_base either.  From stepping thru the code, there are several places 
in the interpreter core that PyType_Ready is called for types whose 
tp_base has not been initialized yet.

PyType_Ready is called for each class in tp_bases.
This is done in typeobject.c::best_base()
Isn't it the case in your program?

Forget my last remark: it applies to heap types (created with
type_new()) and not to static types.

However, it seems that a non-ready class in tp_bases can happen only
when an extension type inherits from another extension type.
It is good practice to call PyType_Ready() on every type you define
(otherwise tp_methods doesn't work); doesn't this answer the initial
problem?

This doesn't address the discrepancy between tp_base and tp_bases.
If multiple bases are used, it's no longer 'good practice', it's an
absolute requirement.  IMO, it should call PyType_Ready for all bases, 
or none of them.

Since the code assumes that all bases have been
initialized, it could at least ASSERT so, rather than crashing deep
within the mro calculations.

My knowledge may be out of date, but I thought multiple inheritance was only supported at the python level.  If this is still the case, then no initialization check is needed. (You cannot get an uninitialized type at python level.)  An extra defensive assert is usually not a bad thing in the code, but in this particular case one would need a loop with checks and it does not seem justified.

-1