Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #79890

Re: .write() behavior

From Marko Rauhamaa <marko@pacujo.net>
Newsgroups comp.lang.python
Subject Re: .write() behavior
Date 2014-10-29 08:00 +0200
Organization A noiseless patient Spider
Message-ID <8761f376vt.fsf@elektro.pacujo.net> (permalink)
References (6 earlier) <544e2cf2$0$13009$c3e8da3$5496439d@news.astraweb.com> <m2llqj$oju$1@reader1.panix.com> <87bnoxv91p.fsf@elektro.pacujo.net> <87tx2otv9s.fsf@elektro.pacujo.net> <w2dzjcffor9.fsf_-_@scooby-doo.csail.mit.edu>

Show all headers | View raw


Alan Bawden <alan@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

Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Status of side-effecting functions in python Rustom Mody <rustompmody@gmail.com> - 2014-10-25 10:27 -0700
  Re: Status of side-effecting functions in python Wolfgang Maier <wolfgang.maier@biologie.uni-freiburg.de> - 2014-10-25 23:41 +0200
    Re: Status of side-effecting functions in python Dan Sommers <dan@tombstonezero.net> - 2014-10-25 22:22 +0000
      Re: Status of side-effecting functions in python Terry Reedy <tjreedy@udel.edu> - 2014-10-25 18:53 -0400
    Re: Status of side-effecting functions in python wxjmfauth@gmail.com - 2014-10-26 00:45 -0700
      Re: Status of side-effecting functions in python Dan Sommers <dan@tombstonezero.net> - 2014-10-26 13:41 +0000
        Re: Status of side-effecting functions in python Rustom Mody <rustompmody@gmail.com> - 2014-10-26 07:53 -0700
        Re: Status of side-effecting functions in python wxjmfauth@gmail.com - 2014-10-26 09:26 -0700
          Re: Status of side-effecting functions in python Marko Rauhamaa <marko@pacujo.net> - 2014-10-26 18:50 +0200
          Re: Status of side-effecting functions in python Roy Smith <roy@panix.com> - 2014-10-26 17:56 -0400
            Re: Status of side-effecting functions in python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-10-27 22:30 +1100
              Re: Status of side-effecting functions in python Chris Angelico <rosuav@gmail.com> - 2014-10-27 22:44 +1100
              Re: Status of side-effecting functions in python Roy Smith <roy@panix.com> - 2014-10-27 09:28 -0400
              Re: Status of side-effecting functions in python Grant Edwards <invalid@invalid.invalid> - 2014-10-27 14:45 +0000
                Re: Status of side-effecting functions in python Marko Rauhamaa <marko@pacujo.net> - 2014-10-27 17:14 +0200
                Re: Status of side-effecting functions in python Nobody <nobody@nowhere.invalid> - 2014-10-28 03:52 +0000
                Re: Status of side-effecting functions in python Marko Rauhamaa <marko@pacujo.net> - 2014-10-28 11:07 +0200
                Re: Status of side-effecting functions in python Marko Rauhamaa <marko@pacujo.net> - 2014-10-28 11:10 +0200
                .write() behavior Alan Bawden <alan@scooby-doo.csail.mit.edu> - 2014-10-29 01:06 -0400
                Re: .write() behavior Marko Rauhamaa <marko@pacujo.net> - 2014-10-29 08:00 +0200
                Re: .write() behavior Alan Bawden <alan@scooby-doo.csail.mit.edu> - 2014-10-31 16:32 -0400
    Re: Status of side-effecting functions in python Grant Edwards <invalid@invalid.invalid> - 2014-10-27 14:22 +0000

csiph-web