Class Variable Access and Assignment
steve at REMOVETHIScyber.com.au
Sun Nov 6 01:11:48 CET 2005
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
More information about the Python-list