On 3/4/07, Adam Olsen <[EMAIL PROTECTED]> wrote: > On 3/4/07, Daniel Stutzbach <[EMAIL PROTECTED]> wrote:
> > .nonblockflush() would be fine with me, but I don't think .flush() > > should block on a non-blocking object. ... I don't think flush should even be called on an object that is (intentionally) non-blocking. The fact that it was called suggests that the application doesn't realize/care about the non-blocking mode. (Or at least doesn't like it at this particular moment.) > > How about .flush() write as much as it can, and throw an exception if > > not all of the bytes can be written to the device? (again, this would > > only come up when a user has set the underlying file descriptor to > > non-blocking mode) > I see little point in having an interface that randomly fails > depending on the stars, phase of the moon, etc. If the application is > using the interface wrong then we should fail every time. (Based on the fflush information at http://opengroup.org/onlinepubs/007908799/xsh/fflush.html) Random failures are unavoidable; the application can't know how full the disk already was. (ENOSPC) The reason not to raise a would-block exception (EAGAIN) is that the application *can* recover by just waiting a while. The boilerplate to do that wait-and-recover should be handled once by python, instead of repeated in every paranoid application that worries it *might* be handed a device that *happens* to be non-blocking. -jJ _______________________________________________ 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
