[Python-Dev] Possible py3k io wierdness (original) (raw)

Brian Quinlan brian at sweetapp.com
Sun Apr 5 11:07:48 CEST 2009


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 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



More information about the Python-Dev mailing list