Augmented Assignment (was: Re: PEP scepticism)

Emile van Sebille emile at fcfw.fenx.com
Sun Jul 1 22:34:07 EDT 2001


----- Original Message -----
From: "Delaney, Timothy" <tdelaney at avaya.com>
To: "'Emile van Sebille'" <emile at fenx.com>; <python-list at python.org>
Sent: Sunday, July 01, 2001 5:59 PM
Subject: RE: Augmented Assignment (was: Re: PEP scepticism)


> > It's nothing that examining the id doesn't resolve:
> >
> > >>> a = [1,2,3]
> > >>> id(a)
> > 18916180
> > >>> a += [4,5]
> > >>> a
> > [1, 2, 3, 4, 5]
> > >>> id(a)
> > 18916180
> > >>> b = (1,2,3)
> > >>> id(b)
> > 15261292
> > >>> b += (4,5)
> > >>> b
> > (1, 2, 3, 4, 5)
> > >>> id(b)
> > 18736580
> > >>>
>
> Actually, that's not quite true. It would be quite legal for id(b) to be
> identical in one case - since b is the only reference to the tuple, the
> original tuple could be collected, and a new tuple with the same id() could
> be allocated. It's unlikely, but possible.
>
> Tim Delaney
>

I'm not sure that's true.  It looks like the old (collectible) reference exists until the STORE_FAST is executed, and IIRC,
individual byte code commands are atomic and execute until completion without interference.

Do I have that right?

>>> def test():
 b += (4,5)

>>> import dis
>>> dis.dis(test)
          0 SET_LINENO               1

          3 SET_LINENO               2
          6 LOAD_FAST                0 (b)
          9 LOAD_CONST               1 (4)
         12 LOAD_CONST               2 (5)
         15 BUILD_TUPLE              2
         18 INPLACE_ADD
         19 STORE_FAST               0 (b)
         22 LOAD_CONST               0 (None)
         25 RETURN_VALUE


Emile van Sebille
emile at fenx.com

---------





More information about the Python-list mailing list