Newbie: tuple list confusion.

[Alex Martelli]

John Roth <newsgroups at jhrothjr.com> wrote:

> "Alex Martelli" <aleaxit at yahoo.com> wrote in message 
> news:1gk1n7i.2du2ju1d38wwgN%aleaxit at yahoo.com...
> > Elaine Jackson <elainejackson7355 at home.com> wrote:
> >
> >> In addition to what you've found out already, there is another difference
> >> that, to my mind, is of paramount importance; namely, the fact that an
> >> augmented assignment (a+=b) is actually not an assignment at all. An
> >> actual assignment (a=a+b) binds the name "a" to a new object, while a
> >> so-called augmented assignment mutates the object a itself.
> >
> > Ah, careful there: augmented assignment (nothing "so-called" about it;-)
> > mutates the object and THEN assigns ("re-binds" if you want to get
> > technical) the name or other slot holding the object.
> 
> I've never understood why it does that. If you have a mutable object
> that is updated, then the rebinding makes no sense whatsoever.

I guess the point is that:

T = (X,)
T[0] += Y

*MUST* fail, whatever X's type; having it fail when (e.g.) type(X) is
str and succeed when type(X) is list would be strange...

> The problem is that it's not just confusing, I think I  have a
> reasonable expectation that if it fails, it fails atomically.

I guess the problem here is that we can't be sure that the semantics of,
say,
   T[x] = T[x]
are to either fail or be a no-operation, and in the latter case future
assignments to T[x] won't fail.  That depends on type(T)... and I don't
see other ways to ensure 'atomicity' -- we can't afford to deepcopy X
before calling X.__iadd__, after all, just to try and ensure we can
"undo" the effect of the latter.

If you disagree with the details of T[x] += y chosen semantics (and I
can well see why one might), I think you should get together with others
who agree with you and put together a PEP in time for Python 3000, which
will probably be the one and only chance to introduce incompatible
changes in this matter (like in others).  While I can sympathize with
your qualms, I think that preparing a PEP to specify precisely what
should happen in such cases will help you see why the current semantics
were chosen.  Similarly for someobj.anattr += whatever and so on, of
course.  Python 3000 is years away, so it's not an urgent matter, but
without such a PEP I think I can predict these details won't change.


Alex