Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsfeed.xs4all.nl!newsfeed4.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Date: Wed, 12 Mar 2014 10:39:35 +0100
From: Antoon Pardon <antoon.pardon@rece.vub.ac.be>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20131103 Icedove/17.0.10
MIME-Version: 1.0
To: python-list@python.org
Subject: Re: Tuples and immutability
References: <lennh4$kpm$1@cabale.usenet-fr.net> <mailman.7427.1393517631.18130.python-list@python.org> <lenp14$m8f$1@cabale.usenet-fr.net> <CAPTjJmrdd+yxnfyBqO45pZfx8hFyWxOeEkx9zgdm842x-qhF+g@mail.gmail.com> <CAHkxivfZjqNa2hCbQiyPLSvJ=VBy7nstj3caA2Yu0NUBKR9AHg@mail.gmail.com> <mailman.7446.1393539531.18130.python-list@python.org> <0d76f320-a39e-44e9-85a2-74220b646566@googlegroups.com> <mailman.8071.1394594751.18130.python-list@python.org> <531ffe70$0$2923$c3e8da3$76491128@news.astraweb.com>
In-Reply-To: <531ffe70$0$2923$c3e8da3$76491128@news.astraweb.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.8076.1394617178.18130.python-list@python.org>
Lines: 61
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python: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'