> The additional warnings aren't critical. But in retrospection I think > that I made a small error during the design of the closefd feature. > With a file descriptor number as first argument and closefd set to > false, the file descriptor isn't closed when the file object is > deallocated. It's also impossible to close the fd with close(). Right > now close() doesn't do anything and you can still write or read after > close(). This behavior is surprising to the user.
However, this is the documented behavior: "the underlying file descriptor will be kept open when the file is closed." and, for close "Flush and close this stream." It would help if the documentation of close would read "Flush and close this stream. This method has no effect if the file is already closed, or if closefd was False when the file object was created." It might be useful if closefd attribute could be reflected, so that applications that know about it and really want to close the file still can do that. Also, is it really the case that close has no effect if closefd was given? ISTM that it will still flush the file, for a _BufferedIOMixin. This should systematically be clarified: it should either always flush, or never (although "always flush" seems more useful). Also, why does the _BufferedIOMixin discard exceptions from flush? Errors should never pass silently. Also, why does the FileIO.close first invoke _FileIO.close, then RawIOBase.close? IIUC, FileIO.close will close the file handle, yet RawIOBase will attempt to flush afterwards. > Maybe the warning could be dropped all along, too. That sounds useful. Regards, Martin _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
