Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #11978
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Subject | Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") |
| Date | 2011-08-21 20:35 -0400 |
| References | <8c606fc1-0aa8-4113-b607-e46ad6f3d649@glegroupsg2000goo.googlegroups.com> <pan.2011.08.21.21.07.55.886000@nowhere.com> |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.294.1313974278.27778.python-list@python.org> (permalink) |
On 8/21/2011 5:07 PM, Nobody wrote:
> If the value on the left has an __iadd__ method, that will be called;
Correct
> the value will be updated in-place,
Not necessarily correct. The target is rebound to the return from the
__iadd__ method. Augmented *assignment* is always assignment. This trips
up people who try
t = (1, [])
t[1] += [1,2] # which *does* extend the array, but raises
TypeError: 'tuple' object does not support item assignment
# instead of
t[1].extend([1,2]) # which extends without raising an error
*IF* (and only if) the target object is mutable, then the __iadd__ may
optionally mutate the target object. But the rebinding takes place
nonetheless. Numbers, the subject of this thread, are not mutable and
are not 'updated in-place'
class test:
def __init__(self, n):
self.n = n
def __iadd__(self, other):
return test(self.n + other.n)
def __repr__(self):
return repr(self.n)
r = test(1)
t = r
t += r
print(r, t)
# 1,2
That said, there is normally no reason to write an __ixxx__ method
unless instances are mutable and the operation can be and is done in
place therein. So the class above is for illustrative purposes only. A
saner example is the following, which treats test examples as mutable
number containers rather than as immutable surrogates.
class test:
def __init__(self, n):
self.n = n
def __add__(self, other):
return test(self.n + other.n)
def __iadd__(self, other):
n = self.n + other.n
self.n = n
return n
def __repr__(self):
return repr(self.n)
r = test(1)
t = r
t += r
print(r, t)
# 2 2
The interpreter cannot enforce that 'x += a' have the same effect as 'x
= x+a', but it would break normal expectations to make the two different.
> so all references to that object will be affected:
Only if the target object is mutable and is mutated by the optional
augmented assignment __ixxx__ methods.
> > import numpy as np
> > a = np.zeros(3)
Numpy arrays meet the qualification above.
> If the value on the left doesn't have an __iadd__ method, then addition is
> performed and the name is re-bound to the result:
As is also done with the results of __ixxx__ methods.
--
Terry Jan Reedy
Back to comp.lang.python | Previous | Next — Previous in thread | Find similar | Unroll thread
relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Laurent <laurent.payot@gmail.com> - 2011-08-21 09:52 -0700
Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") woooee <woooee@gmail.com> - 2011-08-21 09:59 -0700
Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Laurent <laurent.payot@gmail.com> - 2011-08-21 10:03 -0700
Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Irmen de Jong <irmen@-NOSPAM-xs4all.nl> - 2011-08-21 19:14 +0200
Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Hans Mulder <hansmu@xs4all.nl> - 2011-08-21 19:57 +0200
Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Nobody <nobody@nowhere.com> - 2011-08-21 22:07 +0100
Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Laurent Payot <laurent.payot@gmail.com> - 2011-08-21 16:49 -0700
Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Terry Reedy <tjreedy@udel.edu> - 2011-08-21 22:15 -0400
Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Terry Reedy <tjreedy@udel.edu> - 2011-08-21 20:35 -0400
csiph-web