[Python-3000] Draft PEP for New IO system

[Adam Olsen]

On 3/4/07, Jim Jewett <jimjjewett at gmail.com> wrote:
> 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)

I wouldn't call a full disk a random failure, at least not in the same sense.

What I meant was during development, with no disk load by other
processes, the program would work fine.  When deployed a user may have
other apps running and once a week there's just enough disk load that
the flush can't complete immediately.  Then the process exits, it's
still non-blocking so it won't stop, so the file never gets flushed
properly.


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

Making .flush() internally use select() so that it still behaves in a
blocking fashion to the application is perfectly acceptable to me.

The alternative, in my mind at least, is that a TypeError of
ValueError be raised because this interface is not designed to be used
in non-blocking mode and it's bug in the applicatino to attempt it.
The app should be using the right interface instead, .nonblockflush()
or the like.

One interface, one behaviour, no guessing.

-- 
Adam Olsen, aka Rhamphoryncus