On Jan 18, 9:40 am, Marc 'BlackJack' Rintsch <bj_...@gmx.net> wrote: > On Sun, 18 Jan 2009 04:24:04 -0800, andrew cooke wrote: > > my argument was that *= is not treated as = and *, but as a completely > > new operator (the docs even say that the implementation need not return > > self which suggests some pretty extreme semantics were envisaged). > > What do you mean by "suggests … extreme semantics"? Most natural thing > is to use numbers and there you *have* to be able to return something > different than `self` to get anything useful. For instance: > > n *= 3 > > with `n` bound to a number different from zero can't return `self` from > `__imul__`.
in your example, n is not a number, it is a mutable variable, and its value changes. when n is an instance implementing __imul__ the natural analogue is that the internal state of the instance changes. either i have misundertstood you, or you have misunderstood __imul__, or you are treating = as equality, or maybe you are thinking of a pure language that creates new instances? python is impure. anyway, my original request is moot. i was assuming that this was a "capricious" restriction. in fact it's related to what i thought were operators actually being assignments, and so no change is possible (until python 4.0 when guido will finally see the light and move to s- expressions, at which point everyone will stop using the language ;o) andrew -- http://mail.python.org/mailman/listinfo/python-list