On Sat, 05 Nov 2005 21:26:22 +0000, Bengt Richter wrote: > BTW, semantically does/should not __iadd__ really implement a _statement_ and > therefore > have no business returning any expression value to bind anywhere?
We get to practicality versus purity here. Consider x += y for some object type x. If x is a mutable object, then __iadd__ could be a statement, because it can/should/must modify x in place. That is the pure solution. But do you want x += y to work for immutable objects as well? Then __iadd__ cannot be a statement, because x can't be modified in place. Our pure "add in place" solution fails in practice, unless we needlessly restrict what can use it, or have the same syntactical expression (x += y) bind to two different methods (__iadd__ statement, and __riadd__ function, r for return). Either pure solution is yucky. (That's a technical term for "it sucks".) So for practical reasons, __iadd__ can't be a statement, it needs to return an object which gets bound to x. Fortunately, that behaviour works for mutables as well, because __iadd__ simply returns self, which gets re-bound to x. While I am enjoying the hoops people are jumping through to modify the language so that b.a += 2 assigns b.a in the same scope as it was accessed, I'm still rather perplexed as to why you would want that behaviour. It seems to me like spending many hours building a wonderfully polished, ornate, exquisite device for building hiking boots for mountain goats. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list