[Python-Dev] Possible py3k io wierdness

[Brian Quinlan]

Hey Antoine,

Thanks for the clarification!

I see that the C implementation matches the Python implementation but I 
don't see how the semantics of either are useful in this case.

If a subclass implements flush then, as you say, it must also implement 
close and call flush itself before calling its superclass' close method. 
  But then _RawIOBase will pointlessly call the subclass' flush method a 
second time. This second call should raise (because the file is closed) 
and the exception will be caught and suppressed.

I don't see why this is helpful. Could you explain why 
_RawIOBase.close() calling self.flush() is useful?

Cheers,
Brian

Antoine Pitrou wrote:
> Hi!
> 
> <brian <at> sweetapp.com> writes:
>> class _RawIOBase(_FileIO):
> 
> FileIO is a subclass of _RawIOBase, not the reverse:
> 
>>>> issubclass(_io._RawIOBase, _io.FileIO)
> False
>>>> issubclass(_io.FileIO, _io._RawIOBase)
> True
> 
> I do understand your surprise, but the Python implementation of IOBase.close()
> in _pyio.py does the same thing:
> 
>     def close(self) -> None:
>         """Flush and close the IO object.
> 
>         This method has no effect if the file is already closed.
>         """
>         if not self.__closed:
>             try:
>                 self.flush()
>             except IOError:
>                 pass  # If flush() fails, just give up
>             self.__closed = True
> 
> Note how it calls `self.flush()` and not `IOBase.flush(self)`.
> When writing the C version of the I/O stack, we tried to keep the semantics the
> same as in the Python version, although there are a couple of subtleties.
> 
> Your problem here is that it's IOBase.close() which calls your flush() method,
> but FileIO.close() has already done its job before and the internal file
> descriptor has been closed (hence `self.closed` is True). In this particular
> case, I advocate overriding close() as well and call your flush() method
> manually from there.
> 
> Thanks for your feedback!
> 
> Regards
> 
> Antoine.
> 
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/brian%40sweetapp.com