Why not an __assign__ method?

[Carlos Alberto Reis Ribeiro]

I was travelling on the past two days, and I was really surprised to see 
Robin Thomas and Roeland Rengelink proposals. Both examples demonstrate the 
purpose of doing this kind of optimization. Roland's code clearly shows the 
issues here: it is possible for code inside the __add__ method to avoid the 
creation of intermediate objects to store the results, ONLY if we know that 
the current value is a intermediate one, which is our problem now. On the 
other hand Robin's code is transparent and generic, and it avoids the 
problem of determining when an object is bound by cleverly checking the 
reference count.

Some issues that still need to be checked:

- Some mathematical operations cannot be done inplace. The best example 
that I can think of is matrix multiplication (the "true" one, not the 
scalar version). I'm sure there are lots of other mathematical operations 
with this property. The inplace operator implementation needs to take care 
of this anyway, so it may not be a problem.

- Some class libraries do not implement the inplace version as of now. 
There must be a mechanism to fall back to the binary operator version in 
this case. (maybe this is already done - I will check the source for the 
default inplace methods to see if they are calling the binary operators in 
this case)

- Check for any possible side effects for non commutative and/or non 
transitive operations. This is probably not  a problem; I just want to be 
on the safe side.

- The result of the inplace operator and the binary operator MUST be 
exactly the same. If some class library "abuses" this in a non standard 
way, it will break (with good reason).

- Robin's proposal applies to *all* objects. We need to measure the speedud 
of the proposed version to check if the economy in object allocation makes 
up for the extra tests.


Carlos Ribeiro