.write() behavior

[Marko Rauhamaa]

Alan Bawden <alan at scooby-doo.csail.mit.edu>:

> You might be right, because nothing in the Python 2 documentation I
> can find _explicitly_ says that file.write() is guaranteed to write
> everything I told it to, but that seems like a sufficiently surprising
> fact that I would expect the documentation to emphasize the danger.

One can guess that Python2's write tries to push everything into file in
a loop.

> In Python 3 the situation is more puzzling: The documentation for
> open() explains that the type of object returned depends on the mode
> argument, and several possible candidates for the class of the file
> object returned are mentioned. Some of those classes document a
> .write() method that may indeed perform a partial write and return a
> count of how far it got. Other classes don't say that they might do
> partial writes, but neither do they say that they don't do partial
> writes. It seems possible that the _intent_ is that text mode opens
> return a file object that guarantees to always do a full write. But
> maybe not.

Hard to know based on the documentation alone.

Let me mention a related problem I ran into a couple of weeks ago.
Linux's standard C library (glibc) implements fread(3) differently in
RHEL 5 and RHEL 6/7. In RHEL 5, it blocks in a loop until it has read in
the desired number of records. In RHEL 6 and 7, it appears to block
until it can return at least one whole record.

> Am I missing something? There seem to be some primitive IO facilities
> in Python 3 that make a distinction between blocking and non-blocking
> mode, but that distinction doesn't seem to be available when I just
> call open().

I don't think you can do nonblocking I/O with the file.* methods. At
least you shouldn't try.

The solution is to use os.read(), os.write(), os.pipe(), os.fork() et
al. Their semantics is crystal clear.

The same dichotomy is there in C. Do you use stdio facilities or system
calls? Depends on the type of application you are writing.


Marko