Message85900
> 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. |
|
Date |
User |
Action |
Args |
2009-04-12 12:54:29 | pitrou | set | recipients:
+ pitrou, bquinlan |
2009-04-12 12:54:28 | pitrou | link | issue5700 messages |
2009-04-12 12:54:27 | pitrou | create | |
|