Status of side-effecting functions in python

[Grant Edwards]

On 2014-10-27, Steven D'Aprano <steve+comp.lang.python at 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