Message85913
Antoine Pitrou wrote:
> Antoine Pitrou <pitrou@free.fr> added the comment:
>
>> I think that this linearization is probably more useful:
>>
>> MyClass -> io.FileIO -> MyMixin -> IOBase
>
> But why not simply:
>
> MyClass -> MyMixin -> io.FileIO -> IOBase
>
> ?
> Is there something I'm missing that prevents you from doing this?
No, doing this is trivial. But shouldn't it be up to the implementor of
MyClass to decide whether MyMixin or io.FileIO methods are evaluated first?
>> 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.
>
> I understand, but that's at the price of an otherwise useless
> indirection layer, which will also make _pyio even slower that it
> already is :-)
Maybe I misunderstand the purpose of _pyio. The Python 3.1 says that its
purpose is for experimentation. For experimentation, having a Python
implementation where you can add methods and change behavior (though
perhaps not in as deep as way is if this class were completely written
in Python) is useful. It is also useful for the behavior of the Python
implementation to match that of the C implementation as closely as
possible - this patch makes the inheritance graph for _pyio.FileIO more
consistent.
I, for example, want to add a sync() method to FileIO that will call
fsync() on the file's file descriptor. With this change, I have a place
to plug in that change in Python and I can write the C implementation
when I have the Python implementation right.
Cheers,
Brian |
|
Date |
User |
Action |
Args |
2009-04-12 17:44:11 | bquinlan | set | recipients:
+ bquinlan, pitrou |
2009-04-12 17:44:09 | bquinlan | link | issue5700 messages |
2009-04-12 17:44:08 | bquinlan | create | |
|