Antoine Pitrou <pit...@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. > 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue5700> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
