[Python-Dev] Possible py3k io wierdness
brian at sweetapp.com
Sun Apr 5 11:07:48 CEST 2009
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?
Antoine Pitrou wrote:
> <brian <at> sweetapp.com> writes:
>> class _RawIOBase(_FileIO):
> FileIO is a subclass of _RawIOBase, not the reverse:
>>>> issubclass(_io._RawIOBase, _io.FileIO)
>>>> issubclass(_io.FileIO, _io._RawIOBase)
> 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:
> 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!
> Python-Dev mailing list
> Python-Dev at python.org
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/brian%40sweetapp.com
More information about the Python-Dev