[Python-3000] Draft PEP for New IO system

[Jim Jewett]

On 3/4/07, Adam Olsen <rhamph at gmail.com> wrote:
> On 3/4/07, Daniel Stutzbach <daniel.stutzbach at gmail.com> 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