[Patches] Augmented assignment

[Tim Peters]

[Michael Hudson]
> After a resounding silence on comp.lang.python, I thought I'd try
> here.

My silence should be interpreted as hearty encouragement!  This is one of
those things so *interesting* that I can't make time to comment on it <0.1
wink>.

> ...
> I have taken the Common Lisp approach of evaluating things as little as
> possible; so in the expression
>
> e1[e2] += e3
>
> each of e3, e1 and e2 are evaluated (in that order) once, though
> obviously the result of e1 has both BINARY_SUBSCR and STORE_SUBSCR
> done to it.

"only once" is the only way it will ever get in, so that part is dead right.
Guido never wrote down his order-of-evaluation rules, but I'm going to
channel him here and just decree that you got that part right too <wink>.

> The stack gymnastics required to pull this off look like an attempt to
> generate S_3 given a 3-cycle (ROT_THREE) and a 2-cycle (ROT_TWO), so the
> resulting code could be much simplified with a couple of well chosen
> stack manipulation opcodes.

Good idea.

> ...
> Comments, flames, etc welcome, but I'm not subscribed to patches, so
> I'd appreciate being Cc-ed on any responses.

I predict you're going to be totally ignored in the rush to finish 1.6 --
and IMO there are already too many "big" changes getting introduced so late
in the release cycle.  Just don't let that discourage you!

> ...
> And, I don't expect the patch to go in in this form ...

It probably won't go in before a means to allow overloading += etc (distinct
from __add__ etc) is also implemented.  That is, if the NumPy folks can't
overload += to do in-place mutation of the LHS, you're not going to get
enough political clout to overcome Guido's frown <wink>.