Status of side-effecting functions in python

Grant Edwards invalid at invalid.invalid
Mon Oct 27 15:45:39 CET 2014


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            



More information about the Python-list mailing list