[issue5700] io.FileIO calls flush() after file closed

Brian Quinlan report at bugs.python.org
Sun Apr 12 19:44:11 CEST 2009


Brian Quinlan <brian at sweetapp.com> added the comment:

Antoine Pitrou wrote:
> Antoine Pitrou <pitrou at 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

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5700>
_______________________________________


More information about the Python-bugs-list mailing list