2013/8/25 Armin Ronacher <[email protected]> > Hi, > > > On 23/08/2013 19:36, Graydon Hoare wrote: > >> Could you say more (perhaps more constructively)? I believe we have >> every intention to support these sorts of overloads longer-term; we >> removed the previous support only because it wasn't done terribly well. >> > I think augmented assignments in Python are fine, but they do have some > edge cases. The most famous one (as this is generally brought up as Python > WTF on various parts of the interwebs) is the one where a mutable element > within an immutable structure is modified: > > >>> a = ([42],) > >>> a[0] += [23] > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > TypeError: 'tuple' object does not support item assignment > >>> a > ([42, 23],) > > The reason for this is that `a[0] += [23]` expands to > `type(a[0]).__iadd__(a[0], [23])` but afterwards a[0] is overridden with > a[0]. > > Aside from that I believe += and friends are just fine. Some people > raised concern that `a = a + [2]` makes a new list but `a += [2]` modifies > a list in place, but I think that is pretty obvious from looking at the > code. >
I also think Python's argumented assignments are fine and both a += b vs a + b should behave differently. I personally read a += b as an atomic, thread-safe operation whereas a + b isn't and I beleive that's the way it shoud be. Expanding a += b to a + b doesn't sound right to me. Anyway, that's my $0.02. FF -- Flavio (@flaper87) Percoco http://www.flaper87.org http://github.com/FlaPer87
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
