[Python-Dev] behavior of inplace operations

[David Abrahams]

----- Original Message -----
From: "Tim Peters" <tim.one@comcast.net>

> Getting single-evaluation requires picturing reference-to-lvalue, or
magical
> writeback proxies, or something else equally convoluted:

No, sorry, it doesn't. All it requires is a straightforward interpretation
of the name given to these operations. You guys called them "inplace". When
I heard that I thought "oh, it just modifies the value in-place. Wait, what
about immutable objects? I guess it must rebind the thing on the LHS to the
new value." Call that convoluted if you want, but at least a few people
seem to approach it that way.

> they're unPythonic simply because Python doesn't have stuff like that.

Just stop right there and sign it "tautology-of-the-week-ly y'rs", OK?

> A protocol was invented
> for supporting both in-place and replacement forms of augmented
assignments
> uniformly, but it's a Pythonically simple protocol in that it can be
> expressed *in* Python with no new concepts beyond that methods like
__iadd__
> exist.

Another simple protocol can also be expressed in Python, but since it
involves an "if" statement it might not be considered "Pythonically
simple". But, y'know, I don't care about this issue that much -- I just
don't like leaving the implication that I'm thinking convolutedly
uncontested. IOW, yer pressing my buttons, Tim! I'm happy to drop the
technical issue unless you want to keep trolling me.

> I don't dispute that it surprises some people some of the time, but
> I submit that any other protocol would surprise some people too.

True. I just think that the trade-offs of the chosen protocol are going to
surprise more people in simpler situations than an alternative would have.
It seems as though clean operation with mutable tuple elements (among other
things) was sacrificed for the sake of transparency with persistent
containers. I would've made a different trade-off, but then I'm not BDFL
around here.

like-a-moth-to-a-flame-ly y'rs,
dave