Why not an __assign__ method?
Carlos Alberto Reis Ribeiro
cribeiro at mail.inet.com.br
Fri Apr 6 18:40:38 EDT 2001
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
More information about the Python-list
mailing list