[Python-3000] Draft PEP for New IO system (original) (raw)
Adam Olsen rhamph at gmail.com
Mon Mar 5 04:12:07 CET 2007
- Previous message: [Python-3000] Draft PEP for New IO system
- Next message: [Python-3000] How far to go with cleaning up exceptions
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-3000] Draft PEP for New IO system
- Next message: [Python-3000] How far to go with cleaning up exceptions
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]