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