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

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

Tuples and immutability

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

Contents

  Tuples and immutability Eric Jacoboni <eric.jacoboni@gmail.com> - 2014-02-27 17:01 +0100
    Re: Tuples and immutability Zachary Ware <zachary.ware+pylist@gmail.com> - 2014-02-27 10:13 -0600
      Re: Tuples and immutability Eric Jacoboni <eric.jacoboni@gmail.com> - 2014-02-27 17:27 +0100
        Re: Tuples and immutability Chris Angelico <rosuav@gmail.com> - 2014-02-28 03:33 +1100
        Re: Tuples and immutability Zachary Ware <zachary.ware+pylist@gmail.com> - 2014-02-27 10:47 -0600
        Re: Tuples and immutability Nick Timkovich <prometheus235@gmail.com> - 2014-02-27 15:47 -0600
        Re: Tuples and immutability Chris Angelico <rosuav@gmail.com> - 2014-02-28 08:52 +1100
        Re: Tuples and immutability Ian Kelly <ian.g.kelly@gmail.com> - 2014-02-27 15:18 -0700
          Re: Tuples and immutability Rick Johnson <rantingrickjohnson@gmail.com> - 2014-03-11 19:01 -0700
            Re: Tuples and immutability Chris Angelico <rosuav@gmail.com> - 2014-03-12 13:10 +1100
            Re: Tuples and immutability Terry Reedy <tjreedy@udel.edu> - 2014-03-11 23:25 -0400
              Re: Tuples and immutability Steven D'Aprano <steve@pearwood.info> - 2014-03-12 06:28 +0000
                Re: Tuples and immutability Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-03-12 10:39 +0100
                Re: Tuples and immutability Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-12 03:40 -0600
                Re: Tuples and immutability Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-12 03:51 -0600
                Re: Tuples and immutability Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-03-12 12:21 +0100
            Re: Tuples and immutability Ethan Furman <ethan@stoneleaf.us> - 2014-03-11 23:32 -0700
            Re: Tuples and immutability Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2014-03-12 10:20 +0000
        Re: Tuples and immutability Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2014-03-01 18:55 +0000
    Re: Tuples and immutability Chris Angelico <rosuav@gmail.com> - 2014-02-28 03:14 +1100
    Re: Tuples and immutability Marko Rauhamaa <marko@pacujo.net> - 2014-02-27 18:19 +0200
      Re: Tuples and immutability John O'Hagan <research@johnohagan.com> - 2014-02-28 16:17 +1100
        Re: Tuples and immutability Marko Rauhamaa <marko@pacujo.net> - 2014-02-28 09:54 +0200
    Re: Tuples and immutability Joshua Landau <joshua@landau.ws> - 2014-02-28 14:41 +0000
    Re: Tuples and immutability Chris Angelico <rosuav@gmail.com> - 2014-03-01 01:43 +1100
      Re: Tuples and immutability Duncan Booth <duncan.booth@invalid.invalid> - 2014-03-07 09:33 +0000
        Re: Tuples and immutability Ben Finney <ben+python@benfinney.id.au> - 2014-03-07 22:04 +1100
        Re: Tuples and immutability Chris Angelico <rosuav@gmail.com> - 2014-03-07 22:11 +1100
        Re: Tuples and immutability Peter Otten <__peter__@web.de> - 2014-03-07 12:38 +0100
        Re: Tuples and immutability Chris Angelico <rosuav@gmail.com> - 2014-03-07 22:45 +1100
        Re: Tuples and immutability Alister <alister.ware@ntlworld.com> - 2014-03-07 11:51 +0000
          Re: Tuples and immutability Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-07 11:23 -0700
        Re: Tuples and immutability Roy Smith <roy@panix.com> - 2014-03-07 08:37 -0500
        Re: Tuples and immutability Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-03-08 15:17 +1300
          Re: Tuples and immutability Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-07 21:17 -0700
            Balanced trees (was: Re: Tuples and immutability) Marko Rauhamaa <marko@pacujo.net> - 2014-03-08 10:34 +0200
              Re: Balanced trees (was: Re: Tuples and immutability) Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-08 04:03 -0700
                Re: Balanced trees Marko Rauhamaa <marko@pacujo.net> - 2014-03-08 13:26 +0200
              Re: Balanced trees (was: Re: Tuples and immutability) Dan Stromberg <drsalists@gmail.com> - 2014-03-08 11:58 -0800
              Re: Balanced trees Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-08 20:37 +0000
                Re: Balanced trees Marko Rauhamaa <marko@pacujo.net> - 2014-03-08 23:21 +0200
                  Re: Balanced trees Roy Smith <roy@panix.com> - 2014-03-08 17:22 -0500
                    Re: Balanced trees Marko Rauhamaa <marko@pacujo.net> - 2014-03-09 11:17 +0200
                  Re: Balanced trees Dan Stromberg <drsalists@gmail.com> - 2014-03-08 17:31 -0800
                    Re: Balanced trees Marko Rauhamaa <marko@pacujo.net> - 2014-03-09 11:27 +0200
                      Re: Balanced trees Dan Stromberg <drsalists@gmail.com> - 2014-03-09 14:20 -0700
                        Re: Balanced trees Marko Rauhamaa <marko@pacujo.net> - 2014-03-09 23:32 +0200
                          Re: Balanced trees Dan Stromberg <drsalists@gmail.com> - 2014-03-09 14:37 -0700
                            Re: Balanced trees Marko Rauhamaa <marko@pacujo.net> - 2014-03-09 23:43 +0200
                              Re: Balanced trees Dan Stromberg <drsalists@gmail.com> - 2014-03-09 15:08 -0700
                                Re: Balanced trees Marko Rauhamaa <marko@pacujo.net> - 2014-03-10 00:24 +0200
                              Re: Balanced trees Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-09 18:04 -0600
                                Re: Balanced trees Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-10 03:24 +0000
                          Re: Balanced trees Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-10 03:24 +0000
                            Re: Balanced trees Marko Rauhamaa <marko@pacujo.net> - 2014-03-10 08:16 +0200
                              Re: Balanced trees Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-10 08:53 +0000
                                Re: Balanced trees Marko Rauhamaa <marko@pacujo.net> - 2014-03-10 11:41 +0200
                                  Re: Balanced trees Ned Batchelder <ned@nedbatchelder.com> - 2014-03-10 06:57 -0400
                                    Re: Balanced trees Rustom Mody <rustompmody@gmail.com> - 2014-03-10 09:01 -0700
                                      Re: Balanced trees Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-11 02:02 +0000
                                        Re: Balanced trees Roy Smith <roy@panix.com> - 2014-03-10 22:20 -0400
                                          Re: Balanced trees Chris Angelico <rosuav@gmail.com> - 2014-03-11 13:29 +1100
                                Re: Balanced trees Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-10 09:51 +0000
                              Re: Balanced trees Roy Smith <roy@panix.com> - 2014-03-10 09:59 -0400
                                Re: Balanced trees Chris Angelico <rosuav@gmail.com> - 2014-03-11 03:20 +1100
                                Re: Balanced trees Chris Angelico <rosuav@gmail.com> - 2014-03-11 03:24 +1100
                                  Re: Balanced trees Marko Rauhamaa <marko@pacujo.net> - 2014-03-10 19:08 +0200
                                    Re: Balanced trees Chris Angelico <rosuav@gmail.com> - 2014-03-11 04:17 +1100
                                      Re: Balanced trees Marko Rauhamaa <marko@pacujo.net> - 2014-03-10 19:34 +0200
                                        Re: Balanced trees Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-13 12:40 -0600
                                        Re: Balanced trees Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-13 23:57 +0000
                                          Re: Balanced trees Dan Stromberg <drsalists@gmail.com> - 2014-03-13 20:12 -0700
                                            Re: Balanced trees Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-14 05:02 +0000
                                    Re: Balanced trees Roy Smith <roy@panix.com> - 2014-03-10 19:24 -0400
                                      Re: Balanced trees Chris Angelico <rosuav@gmail.com> - 2014-03-11 10:27 +1100
                                      Re: Balanced trees Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-11 01:26 +0000
                                        Re: Balanced trees Chris Angelico <rosuav@gmail.com> - 2014-03-11 12:45 +1100
                                        Re: Balanced trees Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-10 21:38 -0600
                                        Re: Balanced trees Chris Angelico <rosuav@gmail.com> - 2014-03-11 15:28 +1100
                                          Re: Balanced trees "Rhodri James" <rhodri@wildebst.org.uk> - 2014-03-12 00:57 +0000
                                        Re: Balanced trees Marko Rauhamaa <marko@pacujo.net> - 2014-03-11 12:12 +0200
                                          Re: Balanced trees alex23 <wuwei23@gmail.com> - 2014-03-12 10:13 +1000
                                      Re: Balanced trees Alister <alister.ware@ntlworld.com> - 2014-03-11 09:25 +0000
                                      Re: Balanced trees Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-03-12 10:08 +0100
                                Re: Balanced trees Tim Chase <python.list@tim.thechases.com> - 2014-03-10 11:33 -0500
                                Re: Balanced trees Chris Angelico <rosuav@gmail.com> - 2014-03-11 03:39 +1100
                                Re: Balanced trees Dan Stromberg <drsalists@gmail.com> - 2014-03-10 18:05 -0700
                                  Re: Balanced trees Roy Smith <roy@panix.com> - 2014-03-10 22:13 -0400
                            Re: Balanced trees Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-03-10 19:57 -0400
              Re: Balanced trees Joshua Landau <joshua@landau.ws> - 2014-03-15 01:13 +0000
                Re: Balanced trees Marko Rauhamaa <marko@pacujo.net> - 2014-03-18 00:05 +0200
                  Re: Balanced trees Dan Stromberg <drsalists@gmail.com> - 2014-03-18 12:26 -0700
                    Re: Balanced trees Marko Rauhamaa <marko@pacujo.net> - 2014-03-18 22:55 +0200
                      Re: Balanced trees Dan Stromberg <drsalists@gmail.com> - 2014-03-18 14:45 -0700
                        Re: Balanced trees Marko Rauhamaa <marko@pacujo.net> - 2014-03-19 00:03 +0200
                          Re: Balanced trees Dan Stromberg <drsalists@gmail.com> - 2014-03-18 15:21 -0700
                            Re: Balanced trees Marko Rauhamaa <marko@pacujo.net> - 2014-03-19 01:11 +0200
                              Re: Balanced trees Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-19 01:15 +0000
                                Re: Balanced trees Marko Rauhamaa <marko@pacujo.net> - 2014-03-19 10:49 +0200
                                  Re: Balanced trees Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-19 13:42 +0000
                                    Re: Balanced trees Marko Rauhamaa <marko@pacujo.net> - 2014-03-19 15:54 +0200
                                    Re: Balanced trees Roy Smith <roy@panix.com> - 2014-03-19 10:06 -0400
                            Re: Balanced trees Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-19 01:15 +0000
                              Re: Balanced trees Ethan Furman <ethan@stoneleaf.us> - 2014-03-19 08:15 -0700
                        Re: Balanced trees "Rhodri James" <rhodri@wildebst.org.uk> - 2014-03-20 02:16 +0000
                          Re: Balanced trees Dan Stromberg <drsalists@gmail.com> - 2014-03-19 19:34 -0700
                      Re: Balanced trees Chris Kaynor <ckaynor@zindagigames.com> - 2014-03-18 18:02 -0700
                  Re: Balanced trees Daniel Stutzbach <stutzbach@google.com> - 2014-03-18 13:18 -0700
              blist in standard library  (was Re: Balanced trees) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-15 12:31 +0000
              Re: Balanced trees Daniel Stutzbach <stutzbach@google.com> - 2014-03-17 14:16 -0700
              Re: Balanced trees Joshua Landau <joshua@landau.ws> - 2014-03-18 00:08 +0000
              Re: Balanced trees Daniel Stutzbach <stutzbach@google.com> - 2014-03-17 18:01 -0700
              Re: Balanced trees Joshua Landau <joshua@landau.ws> - 2014-03-18 07:46 +0000
            Re: Tuples and immutability Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-03-09 13:40 +1300
              Re: Tuples and immutability Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-08 19:39 -0700
                Re: Tuples and immutability Marko Rauhamaa <marko@pacujo.net> - 2014-03-09 11:35 +0200
                Re: Tuples and immutability Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-03-10 11:03 +1300
                  Re: Tuples and immutability Terry Reedy <tjreedy@udel.edu> - 2014-03-09 19:00 -0400
                  Re: Tuples and immutability Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-09 17:42 -0600
                    Re: Tuples and immutability Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-10 02:37 +0000
                      Re: Tuples and immutability Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-10 02:35 -0600
                        Re: Tuples and immutability Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-10 09:13 +0000
                        Re: Tuples and immutability Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-03-11 18:15 +1300
                    Re: Tuples and immutability Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-03-11 18:03 +1300
                      Re: Tuples and immutability Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-11 04:39 -0600
                        Re: Tuples and immutability Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-11 16:46 +0000
                          Re: Tuples and immutability Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-03-12 10:23 +1300
                          Re: Tuples and immutability Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-11 17:06 -0600
                            Re: Tuples and immutability Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-12 23:20 +0000
                              Re: Tuples and immutability Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-12 19:35 -0600
                              Re: Tuples and immutability Terry Reedy <tjreedy@udel.edu> - 2014-03-12 22:09 -0400
            Re: Tuples and immutability Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-03-09 13:45 +1300
              Re: Tuples and immutability Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-08 19:55 -0700
    Re: Tuples and immutability "Mark H. Harris" <harrismh777@gmail.com> - 2014-02-28 16:22 -0800
      Re: Tuples and immutability Eric Jacoboni <eric.jacoboni@gmail.com> - 2014-03-01 02:27 +0100
        Re: Tuples and immutability "Mark H. Harris" <harrismh777@gmail.com> - 2014-02-28 20:45 -0800
          Re: Tuples and immutability Ian Kelly <ian.g.kelly@gmail.com> - 2014-02-28 22:34 -0700
            Re: Tuples and immutability "Mark H. Harris" <harrismh777@gmail.com> - 2014-02-28 21:50 -0800
              Re: Tuples and immutability Ned Batchelder <ned@nedbatchelder.com> - 2014-03-01 12:56 -0500
        Re: Tuples and immutability Ian Kelly <ian.g.kelly@gmail.com> - 2014-02-28 22:26 -0700
      Re: Tuples and immutability Chris Angelico <rosuav@gmail.com> - 2014-03-01 12:39 +1100
      Re: Tuples and immutability Ian Kelly <ian.g.kelly@gmail.com> - 2014-02-28 22:16 -0700
        Re: Tuples and immutability "Mark H. Harris" <harrismh777@gmail.com> - 2014-02-28 22:16 -0800
          Re: Tuples and immutability Chris Angelico <rosuav@gmail.com> - 2014-03-01 17:29 +1100
          Re: Tuples and immutability Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-01 14:54 +0000
            Re: Tuples and immutability "Mark H. Harris" <harrismh777@gmail.com> - 2014-03-01 13:01 -0800
        Re: Tuples and immutability "Mark H. Harris" <harrismh777@gmail.com> - 2014-02-28 22:25 -0800
          Re: Tuples and immutability Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-01 12:45 -0700
        Re: Tuples and immutability "Mark H. Harris" <harrismh777@gmail.com> - 2014-03-01 13:21 -0800
          Re: Tuples and immutability Eric Jacoboni <eric.jacoboni@gmail.com> - 2014-03-02 03:04 +0100
            Re: Tuples and immutability "Mark H. Harris" <harrismh777@gmail.com> - 2014-03-01 18:28 -0800
            Re: Tuples and immutability Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-02 05:32 -0700
              Re: Tuples and immutability Eric Jacoboni <eric.jacoboni@gmail.com> - 2014-03-02 14:38 +0100
                Re: Tuples and immutability Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-02 14:05 +0000
                  Re: Tuples and immutability Eric Jacoboni <eric.jacoboni@gmail.com> - 2014-03-02 15:17 +0100
                    Re: Tuples and immutability "albert visser" <albert.visser@gmail.com> - 2014-03-02 15:37 +0100
          Re: Tuples and immutability "Mark H. Harris" <harrismh777@gmail.com> - 2014-03-01 18:15 -0800
    Re: Tuples and immutability Joshua Landau <joshua@landau.ws> - 2014-03-09 17:54 +0000
    Re: Tuples and immutability Chris Angelico <rosuav@gmail.com> - 2014-03-10 05:13 +1100
    Re: Tuples and immutability Joshua Landau <joshua@landau.ws> - 2014-03-09 19:57 +0000
    Re: Tuples and immutability Chris Angelico <rosuav@gmail.com> - 2014-03-10 07:06 +1100

Page 1 of 9  [1] 2 3 4 5 6 7 8 9  Next page →

#67151 — Tuples and immutability

Hi,

I'm using Python 3.3 and i have a problem for which i've still not found
any reasonable explanation...

>>> a_tuple = ("spam", [10, 30], "eggs")
>>> a_tuple[1] += [20]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'tuple' object does not support item assignment

Ok... I accept this message as += is a reassignment of a_tuple[1] and a
tuple is immutable...

But, then, why a_tuple is still modified?

>>> a_tuple
('spam', [10, 30, 20], 'eggs')

I get a TypeError for an illegal operation, but this operation is still
completed?

[toc] | [next] | [standalone]

#67152

On Thu, Feb 27, 2014 at 10:01 AM, Eric Jacoboni <eric.jacoboni@gmail.com> wrote:
> Hi,
>
> I'm using Python 3.3 and i have a problem for which i've still not found
> any reasonable explanation...
>
>>>> a_tuple = ("spam", [10, 30], "eggs")
>>>> a_tuple[1] += [20]
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: 'tuple' object does not support item assignment
>
> Ok... I accept this message as += is a reassignment of a_tuple[1] and a
> tuple is immutable...
>
> But, then, why a_tuple is still modified?
>
>>>> a_tuple
> ('spam', [10, 30, 20], 'eggs')
>
> I get a TypeError for an illegal operation, but this operation is still
> completed?

You're not the first person to have this question :)

http://docs.python.org/3/faq/programming.html#why-does-a-tuple-i-item-raise-an-exception-when-the-addition-works

-- 
Zach

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

#67156

Le 27/02/2014 17:13, Zachary Ware a écrit :
>
> You're not the first person to have this question :)
> 
> http://docs.python.org/3/faq/programming.html#why-does-a-tuple-i-item-raise-an-exception-when-the-addition-works
> 

Oh yes, i was aware of this explanation (thanks to Chris for his answer,
too)... and that's why i wrote "reasonable" :)
I know i should use append() or extend() and i understand the tricky
implications of += in this context. But, imho, it's far from being a
intuitive result, to say the least.

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

#67157

On Fri, Feb 28, 2014 at 3:27 AM, Eric Jacoboni <eric.jacoboni@gmail.com> wrote:
> But, imho, it's far from being a intuitive result, to say the least.

It's unintuitive, but it's a consequence of the way += is defined. If
you don't want assignment, don't use assignment :)

ChrisA

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

#67158

On Thu, Feb 27, 2014 at 10:27 AM, Eric Jacoboni <eric.jacoboni@gmail.com> wrote:
> Le 27/02/2014 17:13, Zachary Ware a écrit :
>>
>> You're not the first person to have this question :)
>>
>> http://docs.python.org/3/faq/programming.html#why-does-a-tuple-i-item-raise-an-exception-when-the-addition-works
>>
>
> Oh yes, i was aware of this explanation (thanks to Chris for his answer,
> too)... and that's why i wrote "reasonable" :)
> I know i should use append() or extend() and i understand the tricky
> implications of += in this context. But, imho, it's far from being a
> intuitive result, to say the least.

Well, once you understand what's actually going on, it's the result
that you should expect.  The FAQ entry I linked to exists to help
people get to that point.

To answer your specific questions:

> But, then, why a_tuple is still modified?

It is not.  a_tuple is still "('spam', <list object at specific
address>, 'eggs')", exactly the same before and after the attempted
"a_tuple[1] += [20]".  The change is internal to <list object at
specific address>.

> I get a TypeError for an illegal operation, but this operation is still
> completed?

Half completed.  The extension of <list object at specific address>
happened as expected, but the assignment of <list object at specific
address> to a_tuple[1] didn't.  It looks like it did, though, because
the assignment was just trying to assign the same object to the same
index.

-- 
Zach

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

#67166

[Multipart message — attachments visible in raw view] — view raw

On Thu, Feb 27, 2014 at 10:33 AM, Chris Angelico <rosuav@gmail.com> wrote:

> On Fri, Feb 28, 2014 at 3:27 AM, Eric Jacoboni <eric.jacoboni@gmail.com>
> wrote:
> > But, imho, it's far from being a intuitive result, to say the least.
>
> It's unintuitive, but it's a consequence of the way += is defined. If
> you don't want assignment, don't use assignment :)
>
> ChrisA
>

Where is `.__iadd__()` called outside of `list += X`?  If the only
difference from `.extend()` is that it returns `self`, but the list was
already modified anyway, why bother with reassignment?

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

#67168

On Fri, Feb 28, 2014 at 8:47 AM, Nick Timkovich <prometheus235@gmail.com> wrote:
> On Thu, Feb 27, 2014 at 10:33 AM, Chris Angelico <rosuav@gmail.com> wrote:
>>
>> On Fri, Feb 28, 2014 at 3:27 AM, Eric Jacoboni <eric.jacoboni@gmail.com>
>> wrote:
>> > But, imho, it's far from being a intuitive result, to say the least.
>>
>> It's unintuitive, but it's a consequence of the way += is defined. If
>> you don't want assignment, don't use assignment :)
>>
>> ChrisA
>
>
> Where is `.__iadd__()` called outside of `list += X`?  If the only
> difference from `.extend()` is that it returns `self`, but the list was
> already modified anyway, why bother with reassignment?

Not everything handles += that way. You can't mutate the integer 5
into 7 because someone had 5 in x and wrote "x += 2". So it has to
reassign.

Actually, integers just don't define __iadd__, but the principle applies.

ChrisA

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

#67172

On Thu, Feb 27, 2014 at 2:47 PM, Nick Timkovich <prometheus235@gmail.com> wrote:
> On Thu, Feb 27, 2014 at 10:33 AM, Chris Angelico <rosuav@gmail.com> wrote:
>>
>> On Fri, Feb 28, 2014 at 3:27 AM, Eric Jacoboni <eric.jacoboni@gmail.com>
>> wrote:
>> > But, imho, it's far from being a intuitive result, to say the least.
>>
>> It's unintuitive, but it's a consequence of the way += is defined. If
>> you don't want assignment, don't use assignment :)
>>
>> ChrisA
>
>
> Where is `.__iadd__()` called outside of `list += X`?  If the only
> difference from `.extend()` is that it returns `self`, but the list was
> already modified anyway, why bother with reassignment?

x += y is meant to be equivalent, except possibly in-place and more
efficient, than x = x + y.  If you skip the assignment, and that
assignment is meaningful to whatever the left side may be (e.g.
assigning to a descriptor or something that invokes __setitem__ or
__setattr__), then the operation is not equivalent.

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

#68255

On Thursday, February 27, 2014 4:18:01 PM UTC-6, Ian wrote:
> x += y is meant to be equivalent, except possibly in-place and more
> efficient, than x = x + y.  

In an ideal world, the speed of these two codes should be the same, of course i'm "assuming" that most competent language designers would optimise the slower version. 

"""But Rick, Python is an interpreted language and does not benefit from a compile stage."""

Even if the bytecode can't be optimized on the current run, it CAN be optimized by updating the .pyo file for future runs without degrading current (or future) runtime performance.

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

#68256

On Wed, Mar 12, 2014 at 1:01 PM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> On Thursday, February 27, 2014 4:18:01 PM UTC-6, Ian wrote:
>> x += y is meant to be equivalent, except possibly in-place and more
>> efficient, than x = x + y.
>
> In an ideal world, the speed of these two codes should be the same, of course i'm "assuming" that most competent language designers would optimise the slower version.
>

Except that they don't mean the same thing, so it's not an optimization target.

ChrisA

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

#68258

On 3/11/2014 10:01 PM, Rick Johnson wrote:
>
> On Thursday, February 27, 2014 4:18:01 PM UTC-6, Ian wrote:
>> x += y is meant to be equivalent, except possibly in-place and
>> more efficient, than x = x + y.

The manual actually says "An augmented assignment expression like x += 1 
can be rewritten as x = x + 1 to achieve a similar, but not exactly 
equal effect. In the augmented version, x is only evaluated once. Also, 
when possible, the actual operation is performed in-place, meaning that 
rather than creating a new object and assigning that to the target, the 
old object is modified instead.


> In an ideal world, the speed of these two codes should be the same,

Nope, 'similar' is not 'equivalent'. Evaluating x twice instead of once 
and possibly allocating a new object versus not take extra time. In a 
statement like "x.y.z[3*n+m] += 1", calculating the target dominates the 
time to increment, so this form should be nearly twice as fast.

-- 
Terry Jan Reedy

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

#68260

On Tue, 11 Mar 2014 23:25:19 -0400, Terry Reedy wrote:

> On 3/11/2014 10:01 PM, Rick Johnson wrote:
>>
>> On Thursday, February 27, 2014 4:18:01 PM UTC-6, Ian wrote:
>>> x += y is meant to be equivalent, except possibly in-place and more
>>> efficient, than x = x + y.
> 
> The manual actually says "An augmented assignment expression like x += 1
> can be rewritten as x = x + 1 to achieve a similar, but not exactly
> equal effect. In the augmented version, x is only evaluated once. Also,
> when possible, the actual operation is performed in-place, meaning that
> rather than creating a new object and assigning that to the target, the
> old object is modified instead.
> 
> 
>> In an ideal world, the speed of these two codes should be the same,
> 
> Nope, 'similar' is not 'equivalent'. Evaluating x twice instead of once
> and possibly allocating a new object versus not take extra time. In a
> statement like "x.y.z[3*n+m] += 1", calculating the target dominates the
> time to increment, so this form should be nearly twice as fast.

Excellent point Terry!

I always forget that the target of an augmented assignment may not be a 
simple name like "x" but can be an arbitrary complex reference, anything 
that is a legal assignment target. Because += is documented as only 
evaluating the expression once it can behave quite differently to the 
`spam = spam + 1` case. Evaluating the right hand side may have side-
effects that change what the left hand side evaluates to. This is not the 
case with the augmented assignment.

-- 
Steven

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

#68264

Op 12-03-14 07:28, Steven D'Aprano schreef:
> On Tue, 11 Mar 2014 23:25:19 -0400, Terry Reedy wrote:
>
>> Nope, 'similar' is not 'equivalent'. Evaluating x twice instead of once
>> and possibly allocating a new object versus not take extra time. In a
>> statement like "x.y.z[3*n+m] += 1", calculating the target dominates the
>> time to increment, so this form should be nearly twice as fast.
> Excellent point Terry!
>
> I always forget that the target of an augmented assignment may not be a 
> simple name like "x" but can be an arbitrary complex reference, anything 
> that is a legal assignment target. Because += is documented as only 
> evaluating the expression once it can behave quite differently to the 
> `spam = spam + 1` case. Evaluating the right hand side may have side-
> effects that change what the left hand side evaluates to. This is not the 
> case with the augmented assignment.

The documentation is wrong at that point as the following code illustrates.

| import sys
| write = sys.stdout.write
|
| class logdict:
|     def __init__(self):
|         self.lst = {}
|
|     def __setitem__(self, key, value):
|         write('[%s] <= %s\n' % (key, value))
|         self.lst[key] = value
|
|     def __getitem__(self, key):
|         value = self.lst[key]
|         write('[%s] => %s\n' % (key, value))
|         return value
|
| tab = logdict()
| tab['key'] = 'value'
| tab['key'] += ' with extra tail'
| write('====\n')
| tab = logdict()
| tab['key'] = 'value'
| tab['key'] = tab['key'] + ' with extra tail'

If you run this code, you get the following result:

| [key] <= value
| [key] => value
| [key] <= value with extra tail
| ====
| [key] <= value
| [key] => value
| [key] <= value with extra tail

As you can see there is no difference here in the evaluations done
between using

| tab['key'] += ' with extra tail'

or

| tab['key'] = tab['key'] + ' with extra tail'

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

#68265

On Wed, Mar 12, 2014 at 12:28 AM, Steven D'Aprano <steve@pearwood.info> wrote:
> On Tue, 11 Mar 2014 23:25:19 -0400, Terry Reedy wrote:
>> Nope, 'similar' is not 'equivalent'. Evaluating x twice instead of once
>> and possibly allocating a new object versus not take extra time. In a
>> statement like "x.y.z[3*n+m] += 1", calculating the target dominates the
>> time to increment, so this form should be nearly twice as fast.
>
> Excellent point Terry!
>
> I always forget that the target of an augmented assignment may not be a
> simple name like "x" but can be an arbitrary complex reference, anything
> that is a legal assignment target. Because += is documented as only
> evaluating the expression once it can behave quite differently to the
> `spam = spam + 1` case. Evaluating the right hand side may have side-
> effects that change what the left hand side evaluates to. This is not the
> case with the augmented assignment.

Of course one could also do:

    z = x.y.z
    i = 3*n+m
    z[i] = z[i] + 1

which reduces the duplicated work down to storing and loading a couple
of locals, and also prevents side-effects from affecting the LHS
evaluation.

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

#68266

On Wed, Mar 12, 2014 at 3:39 AM, Antoon Pardon
<antoon.pardon@rece.vub.ac.be> wrote:
> The documentation is wrong at that point as the following code illustrates.

Either way it still has to do a getitem and a setitem, but if you have
a more nested structure then the extra getitems are not repeated.  For
example, using your logdict class:

>>> tab = logdict()
>>> tab[1] = logdict()
[1] <= <__main__.logdict object at 0x02A2E430>
>>> tab[1][2] = logdict()
[1] => <__main__.logdict object at 0x02A2E430>
[2] <= <__main__.logdict object at 0x02A2EB10>
>>> tab[1][2][3] = ['value']
[1] => <__main__.logdict object at 0x02A2E430>
[2] => <__main__.logdict object at 0x02A2EB10>
[3] <= ['value']
>>> tab[1][2][3] += [' with extra tail']
[1] => <__main__.logdict object at 0x02A2E430>
[2] => <__main__.logdict object at 0x02A2EB10>
[3] => ['value']
[3] <= ['value', ' with extra tail']

versus:

>>> tab[1][2][3] = ['value']
[1] => <__main__.logdict object at 0x02A2E430>
[2] => <__main__.logdict object at 0x02A2EB10>
[3] <= ['value']
>>> tab[1][2][3] = tab[1][2][3] + [' with extra tail']
[1] => <__main__.logdict object at 0x02A2E430>
[2] => <__main__.logdict object at 0x02A2EB10>
[3] => ['value']
[1] => <__main__.logdict object at 0x02A2E430>
[2] => <__main__.logdict object at 0x02A2EB10>
[3] <= ['value', ' with extra tail']

As you can see the += version does two fewer getitem calls in this case.

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

#68273

Op 12-03-14 10:51, Ian Kelly schreef:
> On Wed, Mar 12, 2014 at 3:39 AM, Antoon Pardon
> <antoon.pardon@rece.vub.ac.be> wrote:
>> The documentation is wrong at that point as the following code illustrates.
> Either way it still has to do a getitem and a setitem, but if you have
> a more nested structure then the extra getitems are not repeated.  For
> example, using your logdict class:

Sure, but the documentation doesn't say for sufficiently nested structures
some evaluations are not repeated.

Take the following example.

| tab['key'] = [1]
| tab['key'] += [2]

Now let us rewrite that second statment in two different ways.

| tab['key'] = tab['key'] + [2]

or

| tmp = tab['key']
| tmp += [2]

Now which of these two rewritings is closer to the augmented concatenation?
A natural reading of the documentation would conclude the second one, because
in that case we only need to evaluate tab['key'] once as righthand sided.
However it turns out the augmented concantenation is closer to the first
rewriting here, evaluating tab['key'] twice once a lefthand sided and once
as right hand sided, which IMO will surprise people that rely on the documentation.

-- 
Antoon Pardon

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

#68261

On 03/11/2014 08:25 PM, Terry Reedy wrote:
> On 3/11/2014 10:01 PM, Rick Johnson wrote:
>>
>> On Thursday, February 27, 2014 4:18:01 PM UTC-6, Ian wrote:
>>> x += y is meant to be equivalent, except possibly in-place and
>>> more efficient, than x = x + y.
>
> The manual actually says "An augmented assignment expression like x += 1 can be rewritten as x = x + 1 to achieve a
> similar, but not exactly equal effect. In the augmented version, x is only evaluated once. Also, when possible, the
> actual operation is performed in-place, meaning that rather than creating a new object and assigning that to the target,
> the old object is modified instead.

... and reassigned to the target.  :)  (If it doesn't say that last part, it should.)

--
~Ethan~

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

#68269

On 12 March 2014 03:25, Terry Reedy <tjreedy@udel.edu> wrote:
> On 3/11/2014 10:01 PM, Rick Johnson wrote:
>>
>>
>> On Thursday, February 27, 2014 4:18:01 PM UTC-6, Ian wrote:
>>>
>>> x += y is meant to be equivalent, except possibly in-place and
>>> more efficient, than x = x + y.
>
>
> The manual actually says "An augmented assignment expression like x += 1 can
> be rewritten as x = x + 1 to achieve a similar, but not exactly equal
> effect. In the augmented version, x is only evaluated once. Also, when
> possible, the actual operation is performed in-place, meaning that rather
> than creating a new object and assigning that to the target, the old object
> is modified instead.
>
>
>
>> In an ideal world, the speed of these two codes should be the same,
>
>
> Nope, 'similar' is not 'equivalent'. Evaluating x twice instead of once and
> possibly allocating a new object versus not take extra time. In a statement
> like "x.y.z[3*n+m] += 1", calculating the target dominates the time to
> increment, so this form should be nearly twice as fast.

An example where the result is semantically different:

>>> from numpy import array
>>> a = array([1, 2, 3], dtype=int)
>>> a
array([1, 2, 3])
>>> a + 1.1
array([ 2.1,  3.1,  4.1])
>>> a += 1.1
>>> a
array([2, 3, 4])

The reason is that numpy arrays are both mutable and have statically
determined elementary data type:

>>> (a + 1.1).dtype
dtype('float64')
>>> a.dtype
dtype('int64')


Oscar

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

#67338

On 27 February 2014 21:47, Nick Timkovich <prometheus235@gmail.com> wrote:
> On Thu, Feb 27, 2014 at 10:33 AM, Chris Angelico <rosuav@gmail.com> wrote:
>>
>> It's unintuitive, but it's a consequence of the way += is defined. If
>> you don't want assignment, don't use assignment :)
>
> Where is `.__iadd__()` called outside of `list += X`?

Numpy uses it for in-place operations with numpy arrays:

>>> import numpy
>>> a = numpy.arange(10)
>>> a
array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9])
>>> a[::2] += 10
>>> a
array([10,  1, 12,  3, 14,  5, 16,  7, 18,  9])

It makes sense for any mutable type that supports +. The stdlib
doesn't have many of these. The obvious one is list but there's also
MutableString (in 2.x):

>>> from UserString import MutableString
>>> a = MutableString("qwe")
>>> a
'qwe'
>>> b = a
>>> b += "asd"
>>> a
'qweasd'

> If the only difference from `.extend()` is that it returns `self`, but the list was
> already modified anyway, why bother with reassignment?

I don't know of any situation where __iadd__ is defined but doesn't
return self and I can't think of a use case apart from operator abuse.

I had thought that the other difference was that .extend would accept
any iterable but it seems += does also. Perhaps that was changed at
some point.

>>> l = [1, 2, 3]
>>> l + (1, 2, 3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can only concatenate list (not "tuple") to list
>>> l += (1, 2, 3)
>>> l
[1, 2, 3, 1, 2, 3]


Oscar

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

#67153

On Fri, Feb 28, 2014 at 3:01 AM, Eric Jacoboni <eric.jacoboni@gmail.com> wrote:
> I'm using Python 3.3 and i have a problem for which i've still not found
> any reasonable explanation...
>
>>>> a_tuple = ("spam", [10, 30], "eggs")
>>>> a_tuple[1] += [20]
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: 'tuple' object does not support item assignment
>
> Ok... I accept this message as += is a reassignment of a_tuple[1] and a
> tuple is immutable...
>
> But, then, why a_tuple is still modified?
>
>>>> a_tuple
> ('spam', [10, 30, 20], 'eggs')
>
> I get a TypeError for an illegal operation, but this operation is still
> completed?

This is a common confusion.

The += operator does two things. First, it asks the target to please
do an in-place addition of the other operand. Then, it takes whatever
result the target gives back, and assigns it back into the target. So
with a list, it goes like this:

>>> foo = [10, 30]
>>> foo.__iadd__([20])
[10, 30, 20]
>>> foo = _

Note that the second step returned a three-element list. Then the +=
operator stuffs that back into the source. In the case of a list, it
does that addition by extending the list, and then returning itself.

The putting-back-into-the-target step fails with a tuple, because a
tuple's members can't be reassigned. But the list has already been
changed by that point. So, when you go to look at it, you see a
changed list.

You can call on this behaviour more safely by using the append() or
extend() methods.

>>> a_tuple = ("spam", [10, 30], "eggs")
>>> a_tuple[1].extend([20])
>>> a_tuple
('spam', [10, 30, 20], 'eggs')

>>> a_tuple = ("spam", [10, 30], "eggs")
>>> a_tuple[1].append(20)
>>> a_tuple
('spam', [10, 30, 20], 'eggs')

(append will add one more element, extend is roughly the same as you
had). Then you're not trying to assign to the tuple, but you're still
mutating the list.

Hope that helps!

ChrisA

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

Page 1 of 9  [1] 2 3 4 5 6 7 8 9  Next page →

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

csiph-web