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


Groups > comp.lang.python > #19785

Re: copy on write

From Hrvoje Niksic <hniksic@xemacs.org>
Newsgroups comp.lang.python
Subject Re: copy on write
Date 2012-02-02 11:53 +0100
Organization B.net Hrvatska d.o.o.
Message-ID <87haz9o6a9.fsf@xemacs.org> (permalink)
References (4 earlier) <4F107AAF.5000600@stoneleaf.us> <20120202141812.649c31d832bb15bd899eb952@johnohagan.com> <CABicbJLKh1Ticp=EDPBWTwESTn5HkDQsopTCWrYH-hY6isOgxQ@mail.gmail.com> <mailman.5348.1328170324.27778.python-list@python.org> <4f2a5478$0$29895$c3e8da3$5496439d@news.astraweb.com>

Show all headers | View raw


Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:

> Perhaps you are thinking that Python could determine ahead of time
> whether x[1] += y involved a list or a tuple, and not perform the
> finally assignment if x was a tuple. Well, maybe, but such an approach
> (if possible!) is fraught with danger and mysterious errors even
> harder to debug than the current situation. And besides, what should
> Python do about non-built-in types? There is no way in general to
> predict whether x[1] = something will succeed except to actually try
> it.

An alternative approach is to simply not perform the final assignment if
the in-place method is available on the contained object.  No prediction
is needed to do it, because the contained object has to be examined
anyway.  No prediction is needed, just don't.  Currently,
lhs[ind] += rhs is implemented like this:

item = lhs[ind]
if hasattr(item, '__iadd__'):
    lhs.__setitem__(ind, item.__iadd__(rhs))
else:
    lhs.__setitem__(ind, item + rhs)
# (Note item assignment in both "if" branches.)

It could, however, be implemented like this:

item = lhs[ind]
if hasattr(item, '__iadd__'):
    item += rhs                  # no assignment, item supports in-place change
else:
    lhs.__setitem__(ind, lhs[ind] + rhs)

This would raise the exact same exception in the tuple case, but without
executing the in-place assignment.  On the other hand, some_list[ind] += 1
would continue working exactly the same as it does now.

In the same vein, in-place methods should not have a return value
(i.e. they should return None), as per Python convention that functions
called for side effect don't return values.

The alternative behavior is unfortunately not backward-compatible (it
ignores the return value of augmented methods), so I'm not seriously
proposing it, but I believe it would have been a better implementation
of augmented assignments than the current one.  The present interface
doesn't just bite those who try to use augmented assignment on tuples
holding mutable objects, but also those who do the same with read-only
properties, which is even more reasonable.  For example, obj.list_attr
being a list, one would expect that obj.list_attr += [1, 2, 3] does the
same thing as obj.list_attr.extend([1, 2, 3]).  And it almost does,
except it also follows up with an assignment after the list has already
been changed, and the assignment to a read-only property raises an
exception.  Refusing to modify the list would have been fine, modifying
it without raising an exception (as described above) would have been
better, but modifying it and *then* raising an exception is a surprise
that takes some getting used to.

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


Thread

copy on write Eduardo Suarez-Santana <esuarez@itccanarias.org> - 2012-01-13 11:33 +0000
  Re: copy on write Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-01-13 12:10 +0000
    Re: copy on write Chris Angelico <rosuav@gmail.com> - 2012-01-13 23:30 +1100
      Re: copy on write Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-01-13 13:04 +0000
        Re: copy on write Ethan Furman <ethan@stoneleaf.us> - 2012-01-13 10:40 -0800
          Re: copy on write 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-13 14:26 -0800
          Re: copy on write 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-13 14:26 -0800
        Re: copy on write John O'Hagan <research@johnohagan.com> - 2012-02-02 14:18 +1100
        Re: copy on write Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-02-02 01:34 -0500
        Re: copy on write John O'Hagan <research@johnohagan.com> - 2012-02-02 19:11 +1100
          Re: copy on write Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-02-02 09:16 +0000
            Re: copy on write Hrvoje Niksic <hniksic@xemacs.org> - 2012-02-02 11:53 +0100
              Re: copy on write MRAB <python@mrabarnett.plus.com> - 2012-02-02 16:28 +0000
              Re: copy on write Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-02-02 12:21 -0500
            Re: copy on write John O'Hagan <research@johnohagan.com> - 2012-02-03 01:17 +1100
            Re: copy on write Terry Reedy <tjreedy@udel.edu> - 2012-02-02 12:25 -0500
            Re: copy on write John O'Hagan <research@johnohagan.com> - 2012-02-03 14:08 +1100
              Re: copy on write Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-02-03 05:04 +0000
                Re: copy on write Chris Angelico <rosuav@gmail.com> - 2012-02-03 16:28 +1100
                Re: copy on write Rick Johnson <rantingrickjohnson@gmail.com> - 2012-02-03 07:35 -0800
                Re: copy on write Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2012-02-03 10:08 +0100
                Re: copy on write John O'Hagan <research@johnohagan.com> - 2012-02-03 21:47 +1100
                Re: copy on write Wolfram Hinderer <wolfram.hinderer@googlemail.com> - 2012-02-05 06:09 -0800
                Re: copy on write "OKB (not okblacke)" <brenNOSPAMbarn@NObrenSPAMbarn.net> - 2012-02-03 16:15 +0000
      Re: copy on write Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2012-02-02 11:42 +0100
    Re: copy on write Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-01-13 08:50 -0500
      Re: copy on write Grant Edwards <invalid@invalid.invalid> - 2012-01-13 15:13 +0000
        Re: copy on write Devin Jeanpierre <jeanpierreda@gmail.com> - 2012-01-13 11:48 -0500
          Re: copy on write Neil Cerutti <neilc@norwich.edu> - 2012-01-13 16:54 +0000
            Re: copy on write Grant Edwards <invalid@invalid.invalid> - 2012-01-13 18:15 +0000
              Re: copy on write Chris Angelico <rosuav@gmail.com> - 2012-01-14 05:26 +1100
                Re: copy on write Grant Edwards <invalid@invalid.invalid> - 2012-01-13 19:30 +0000
                Re: copy on write Neil Cerutti <neilc@norwich.edu> - 2012-01-13 20:11 +0000
            Re: copy on write Evan Driscoll <edriscoll@wisc.edu> - 2012-01-13 13:24 -0600
              Re: copy on write Neil Cerutti <neilc@norwich.edu> - 2012-01-13 21:20 +0000
                Re: copy on write Evan Driscoll <edriscoll@wisc.edu> - 2012-01-13 16:48 -0600
                Re: copy on write 88888 Dihedral <dihedral88888@googlemail.com> - 2012-02-02 05:33 -0800
                Re: copy on write Evan Driscoll <edriscoll@wisc.edu> - 2012-02-02 15:20 -0600
                Re: copy on write 88888 Dihedral <dihedral88888@googlemail.com> - 2012-02-02 05:33 -0800
                Re: copy on write 88888 Dihedral <dihedral88888@googlemail.com> - 2012-02-03 14:16 -0800
                Re: copy on write 88888 Dihedral <dihedral88888@googlemail.com> - 2012-02-03 14:16 -0800
          Re: copy on write Rick Johnson <rantingrickjohnson@gmail.com> - 2012-02-01 19:51 -0800
            Re: copy on write Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-02-02 05:31 +0000

csiph-web