Augmented Assignement (was: Re: PEP scepticism)

[Alex Martelli]

"Paul Prescod" <paulp at ActiveState.com> wrote in message
news:mailman.994112767.3627.python-list at python.org...
    ...
> I shouldn't have said to use proxies instead of mutable integers. I
> meant that you should have proxy x holding mutable integer x' and proxy
> y holding mutable integer y'. Then when you see x+y you can mutate x
> because you claim that you know that there is only ever one reference to
> these objects. That doesn't rely on the person using a particular syntax
> for adding to x.

I may well have other additions to x at other points, that accumulate
to other temporary counts -- e.g. at some point I could have:
    totImportant = mpz(0, mutable=1)
    for key in importantCases:
        totImportant += countOf[key]

Relying on writing this as "totImportant + countOf[key]" rather than
"countOf[key] + totImportant" seems to me far more fragile than
relying on +=.  And if I ever have this in a python -i and when
interactively exploring I write countOf[this}+countOf[that] I
definitely do NOT want this to mess up my further explorations -- I
shudder at the thought.


> How do we "flag" types that have in-place behavior now? How would I
> recognize that your integers were mutable based on anything other than
> reading the documentation or code?

Indeed, while "mutable" vs "immutable" is such a key concept in
Python (from well before += was introduced, of course:-), there
is no direct introspection for it (maybe there SHOULD be!).  If
faced with such a need currently, I would try to check if X is
hashable (if not, it's probably mutable) and if so if its hash()
coincides with its id() (if so, it's probably mutable).  But that
is hardly as solid or reliable as most Python introspection.

But while I can conceive Python growing an ismutable() builtin,
I'd hardly imagine an isadvanced() builtin.  While not fully
pinned down, "mutable" is still a fundamental concept in a way
that "advanced" isn't...


Alex