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

Groups > comp.lang.python > #80056

Re: .write() behavior

Show all headers | View raw

Marko Rauhamaa <marko@pacujo.net> writes:

> 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.

By my reading of the POSIX standard, that latter behavior would be
incorrect.  The "RETURN VALUE" section of the POSIX description for
fread() starts:

   Upon successful completion, fread() shall return the number of
   elements successfully read which is less than nitems only if a read
   error or end-of-file is encountered. ...

If in whatever version of glibc comes with RHEL 6/7, it is the case that
a call to fread() can return less than the desired number of records,
and you have not reached EOF, and no read error has occurred, that would
be a serious bug.  The world is full of C programs that call fread() and
fwrite() without wrapping them in defensive
maybe-I-didn't-get-everything loops.

>> 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().

Since I wrote this, I have discovered and read PEP-3116, and using that
as a road-map to understanding the Python 3 documentation it is now
clear to me that in Python 3, if you have not gone out of your way to
enable non-blocking, a call to the .write() method on any object that
might normally be returned by a call to open(), will always write _all_
of your data (or raise an exception).  There is never any need for a
defensive loop.

As further evidence that this is the case, note that PEP-3116 says right
at the end of its "Rationale and Goals" section:

   ...  Programmers who don't want to muck about in the new I/O world
   can expect that the open() factory method will produce an object
   backwards-compatible with old-style file objects.

Since old-style file objects didn't return a count, this goal can only
be achieved if programmers are safe in _ignoring_ that count in Python 3.

I am relieved to discover that when I am finally able to port my Python
code from Python 2 to Python 3, I will not have to worry that .write()
might perform an incomplete write where it previously did not.

-- 
Alan Bawden

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