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

[Richard Damon]

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