Why not an __assign__ method?

[Carlos Alberto Reis Ribeiro]

Just a question. I did some search around at google and found a few 
messages that were exchanged while PEP203 was being discussed, but no followup.

Relevant messages:
http://groups.google.com/groups?q=__assign__&hl=pt&lr=&safe=off&rnum=1&seld=993477252&ic=1
http://groups.google.com/groups?q=__assign__&hl=pt&lr=&safe=off&rnum=2&seld=999522195&ic=1

The question is: Why not have a __assign__ method, that gets called on 
assignment? It should be called on the *right side* of the expression (at 
the left side it does not make sense - I leave the proof as an exercise for 
the reader <wink>). The return value would be then assigned to the left 
side of the expression. This is the default behavior:

class MyClass:
   def __assign__(self):
     return self

I have thought out this while pondering about some questions on 
optimization of some numerical operations. Take this expression, where a, 
b, and c are all NumPy arrays:

z = a + b + c

Then the expression is broken in steps like this (not exact syntax, but 
enough to give you the idea):

i1 = a.__add__(b)
i2 = i1.__add__(c)
return i2

There are two instantiations of temporary arrays, where only one would be 
enough. With big arrays the extra temp copy is quite an issue. I intend to 
do some image manipulatin, and that surely will help a lot.

The mechanism that I have in mind is:

1) Set a "temp" flag for objects created in the middle of an expression.
2) If a binary operation is called upon a temporary object, use it to store 
the result (of course, if the semantics allows).
3) Reset "temp" on assign.

This has several advantages:

- it allows for the NumPy optimization;
- it may allow for other similar optimizations;
- it does not break any old code, with the exception of the
   ones that implement __assign__; they should not be using
   this name anyway, as it is reserved (double leading
   underscores);
- it is consistent with other similar methods;
- it is much easier than full fledged lazy expression
   evaluation.

The main concerns are:

- it may allow for some very strange errors and bizarre
   behavior if misused;
- the method is called on the right side of the expression,
   which is the opposite of the normal behavior. However
   I don't think it's that bad; after all we have all the
   __r*__ methods.


p.s. Maybe __assign__ is not a good name; maybe something like __onassign__ 
is better, but this does not change the heart of the proposal.



Carlos Ribeiro