On 6/15/18 1:25 PM, Mikhail V wrote: > On Fri, Jun 15, 2018 at 6:54 PM, Chris Angelico <ros...@gmail.com> wrote: >> On Sat, Jun 16, 2018 at 1:48 AM, Mikhail V <mikhail...@gmail.com> wrote: >>> On Fri, Jun 15, 2018 at 5:51 AM, Michael Selik <m...@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 >> 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 _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
