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

Groups > comp.lang.python > #79675 > unrolled thread

Status of side-effecting functions in python

Back to article view | Back to comp.lang.python

Contents

  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

Page 2 of 2 — ← Prev page 1 [2]

#80056 — Re: .write() behavior

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

[toc] | [prev] | [next] | [standalone]

#79784

On 2014-10-25, Wolfgang Maier <wolfgang.maier@biologie.uni-freiburg.de> wrote:

> It may be rare to use an expression both for its side-effects and its
> return value,

It's actually quite common.

For example:

   f = open("filename")
   d = f.readline()

In both of those lines, the side effects and return values are equally
vital.  The same applies to reading from a queue, popping from a
stack, etc.

-- 
Grant Edwards               grant.b.edwards        Yow! This PORCUPINE knows
                                  at               his ZIPCODE ... And he has
                              gmail.com            "VISA"!!

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web