copy on write

[John O'Hagan]

On 03 Feb 2012 05:04:39 GMT
Steven D'Aprano <steve+comp.lang.python at pearwood.info> wrote:

> On Fri, 03 Feb 2012 14:08:06 +1100, John O'Hagan wrote:
> 
> > I think we're 12 years late on this one. It's PEP 203 from 2000 and
> > the key phrase was:
> > 
> > "The in-place function should always return a new reference, either
> > to the old `x' object if the operation was indeed performed
> > in-place, or to a new object."
> > 
> > If this had read:
> > 
> > "The in-place function should return a reference to a new object if
> > the operation was not performed in-place."
> > 
> > or something like that, we wouldn't be discussing this.
> 
> And what should it return if the operation *is* performed in-place?


Not knowing anything about the inner workings of the interpreter, I'm agnostic on that as long as it's not "a new reference". Perhaps the old reference? 

[...snip undoubted reasons why returning None wouldn't work...]

I don't know what would work. Maybe it is insoluble. But didn't Hrvoje Niksic's post in this thread suggest it could have been implemented to work the way I'm saying, even supplying code to demonstrate it?

All I'm saying is that however it's implemented, x[i] += y should simply mutate x[i] in-place if x[i] implements that, otherwise it should do x[i] = x[i] + y. If I can say it under 25 words, surely it's implementable? (Whether it's practical to do so is another question.) 

The x[i] in x[i] += y can be seen as a reference to an object to be incremented rather than an assignment (despite the name). In that view, whether the name x[i] needs to be rebound to a new object, resulting in an assignment, depends on the capabilities of x[i], not x.

> 
> Yes, the current behaviour is a Gotcha, but it's a Gotcha that makes
> good sense compared to the alternatives.

I think it's worse than a Gotcha. IMHO a Gothcha is, for example, the mutable default arguments thing, which makes sense once you get it. This one has the bizarre consequence that what happens when you operate on an object depends on which name you use for the object. Not to mention that it succeeds after raising an exception.

> Ultimately, augmented assignment is *assignment*, just like it says
> on the tin. t[1] += x is syntactic sugar for t[1] = t[1].__iadd__(x).
> It can't and shouldn't fail to raise an exception if t is a tuple,
> because tuple item assignment *must* fail.

That makes sense if we view it strictly as assignment (but in that case the mutation of t[1] should not occur either).
But isn't it equally true if we say that z = t[1], then t[1] += x is syntactic sugar for z = z.__iadd__(x)? Why should that fail, if z can handle it?

[...]
> 
> Ultimately, there is no right answer, because the multitude of 
> requirements are contradictory. No matter what Python did, somebody
> would complain.
> 

Not complaining, just trying to contribute to the best of my ability. :)

John