Newbie: tuple list confusion.
aleaxit at yahoo.com
Mon Sep 13 18:34:59 CEST 2004
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 += 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,
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.
More information about the Python-list