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 pitrou
Recipients bquinlan, pitrou
Date 2009-04-12.12:54:27
SpamBayes Score 5.551115e-17
Marked as misclassified No
Message-id <1239540960.9257.11.camel@fsol>
In-reply-to <>
> 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.

> But it seems like this is the right way to fix this problem anyway - as
> a user, I would expect isinstance(FileIO(...), IOBase) but that is not
> currently the case with _pyio.

That's because the reference ABCs are defined in the io module, not in

>>> issubclass(_pyio.FileIO, io.IOBase)
>>> issubclass(io.TextIOWrapper, io.IOBase)
>>> issubclass(_pyio.TextIOWrapper, io.IOBase)

_pyio.IOBase and friends are just concrete implementations of those

>>> issubclass(_pyio.TextIOBase, io.TextIOBase)

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.
Date User Action Args
2009-04-12 12:54:29pitrousetrecipients: + pitrou, bquinlan
2009-04-12 12:54:28pitroulinkissue5700 messages
2009-04-12 12:54:27pitroucreate