On Jan 18, 6:56 am, andrew cooke <and...@acooke.org> wrote: > 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
Not sure if this ties in, but: >>> ['a'].__imul__(2) ['a', 'a'] -- http://mail.python.org/mailman/listinfo/python-list