[Python-3000] Draft PEP for New IO system (original) (raw)
Jim Jewett jimjjewett at gmail.com
Mon Mar 5 02:50:37 CET 2007
- Previous message: [Python-3000] Draft PEP for New IO system
- Next message: [Python-3000] Draft PEP for New IO system
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-3000] Draft PEP for New IO system
- Next message: [Python-3000] Draft PEP for New IO system
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]