Relax Syntax for Augmented Arithmetic?

[Aaron Brady]

On Jan 18, 6:56 am, andrew cooke <and... at acooke.org> wrote:
> On Jan 18, 9:40 am, Marc 'BlackJack' Rintsch <bj_... at 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']