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 <1239537041.45.0.943211184648.issue5700@psf.upfronthosting.co.za>
Content
> 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
_pyio:

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

_pyio.IOBase and friends are just concrete implementations of those
ABCs:

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

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.
History
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