On 2014-10-27, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: > Roy Smith wrote: > >>> Yes and no. If something goes wrong in a .write() method, >>> is not Python supposed to raise an error? (!) >> >> Define "wrong". It is not an error for a write() call to consume fewer >> bytes than were requested. > > It's not? I'm asking a genuine question here, not a rhetorical one.
No. Under Unix/Posix a write() call may _always_ write fewer bytes than requested. It may be that the device/pipe/file whatever has filled and blocking is disabled. It may be that the device has decided that, at the moment, it can only handle a certain amount of data for some other reason. For example: Let's say you're writing to a network connection that must segment data, and you try to write more than will fit in the current segment. The write() call may fill the segment, send the segment, and "refuse" the rest of the data -- requiring that you make a subsequent write() with the remaining data (at which point it will start a new segment). Or, it may be because the system call was interrupted by something completely unrelated to your program, the write() call, or the "thing" to which you're writing [and it was more convenient for whoever wrote the OS to do a partial write than it was to try to resume the write]. If you really want to make sure that all bytes get written, you _must_ put all write() calls in a loop that checks the return value and keeps re-writing any unwritten data. And to answer your next question: yes, Unix application programmers have been complaining about that (perhaps justifiably) since 1970. -- Grant Edwards grant.b.edwards Yow! I have a TINY BOWL in at my HEAD gmail.com -- https://mail.python.org/mailman/listinfo/python-list