On 6/15/18 1:25 PM, Mikhail V wrote:
On Fri, Jun 15, 2018 at 6:54 PM, Chris Angelico <rosuav@gmail.com> wrote:
On Fri, Jun 15, 2018 at 5:51 AM, Michael Selik <mike@selik.org> wrote:
If you would like to prove the need for this operator, one piece of evidence you can provide is a count of the number of times someone writes "list.append" for an iterable vs "+=" and encloses a str or other type in a throw-away list to effectively append. That's strange idea - there is no doubt that one would use list.append() and most probably it is the case statistically. So the question would be "what is wrong with list.append()?" And as said many times, there is nothing wrong, but a lot of people seem to want an in-place operator for this purpose. And I can understand this, because:
1. append() is _ubiquitous_ 2. in-place assignment form makes some emphasis on mutating, in contrast to method call. How so? You can write "x += 1" with integers, and that doesn't mutate; but if you write "x.some_method()", doing nothing with the return value, it's fairly obvious that it's going to have side effects, most
On Sat, Jun 16, 2018 at 1:48 AM, Mikhail V <mikhailwas@gmail.com> wrote: likely to mutate the object. Augmented assignment is no better than a method at that.
How it would be obvious unless you test it or already have learned by heart that x.some_method() is in-place? For a list variable you might expect it probably, and if you already aware of mutability, etc.
It s just very uncommon to see standalone statements like: x.method()
for me it came into habit to think that it lacks the left-hand part and =. Of course augmented assignment is not a panacea because it is limited only to one operation, and the appeal of the operator itself is under question.
As for x+=1 it is implementation detail - historical idea of such operators was mutating, so at least visually its not like a returning expression. and I am not sure about x.method() form - was it meant to hint to the user about anything? It seemed to me so when I started to learn Python, but its not.
For me if I see foo.bar() my assumption is that likely bar() is going to mutate foo, especially if it doesn't produce a return value, and this is the natural way to define something that mutates something. If it returns something, it might be just an accessor, or it might be a bit of both, easily a mutation that returns a status about the success/failure of the mutation. foo = bar would seem to be never a 'mutation', but always a rebinding of foo, even if 'bar' is an expression using foo. foo += bar, conceptually reads as foo = foo + bar, so the first impression is that it isn't going to mutate, but rebind, but it is possible that it does an inplace rebind so to me THAT is the case where I need to dig into the rules to see what it really does. This means that at quick glance given: list1 = list list1 += value it is unclear if list would have been changed by the +=, while a statement like list1.append(value) is more clearly an in place mutation so other names bound to the same object are expected to see the changes. -- Richard Damon