Antoine Pitrou wrote:
> Antoine Pitrou <pitrou@free.fr> added the comment:
> 
>> It is necessary to make MI work. With out it the inheritance graph looks
>> like this (using _pyio):
>>
>>
>> io.IOBase    _pyio.IOBase
>>     |              |
>> io.FileIO       MyMixin
>>     |              |
>>      \            /
>>       \          /
>>        \        /
>>          MyClass
> 
> MyMixin doesn't need to inherit from IOBase, since precisely it is a
> mixin. It's just a piece of functionality that you drop into an already
> existing inheritance tree.

In my implementation, it does. Otherwise the linearization of the class 
hierarchy becomes:

MyClass -> io.FileIO -> io.IOBase -> MyMixin (-> _pyio.IOBase)

But io.IOBase doesn't make super calls so MyMixin method won't be called.

I think that this linearization is probably more useful:

MyClass -> io.FileIO -> MyMixin -> IOBase

And you get that when io.FileIO and MyMixin share the same IOBase as a 
base class.

I don't mind changing io.IOBase to make super calls in ._close() and 
.flush() and suppressing the attributes errors that will be generated if 
a mixin is not present - but it feels a bit untidy to me.

[snipped]

> I know it looks a bit non-intuitive at first, but the point is that the
> ABCs are unified, even there are two different implementations. I think
> it's better than having two different sets of ABCs depending on whether
> you import the pure-Python version or the C version.

I'm not trying to change the ABC unification at all - and if I did then 
there is a bug in my code. I just think that the immediate parent class 
of _pyio.FileIO should be _pyio.IOBase (just like _io.FileIO has 
_io.IOBase as an immediate parent). That will make the Python and C 
class hierarchies completely consistent within themselves.

Cheers,
Brian