[Python-ideas] Operator for inserting an element into a list

Richard Damon Richard at Damon-Family.org
Fri Jun 15 13:55:40 EDT 2018

On 6/15/18 1:25 PM, Mikhail V wrote:
> On Fri, Jun 15, 2018 at 6:54 PM, Chris Angelico <rosuav at gmail.com> wrote:
>> On Sat, Jun 16, 2018 at 1:48 AM, Mikhail V <mikhailwas at gmail.com> wrote:
>>> On Fri, Jun 15, 2018 at 5:51 AM, Michael Selik <mike at 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

More information about the Python-ideas mailing list