Python Source Code Beautifier

[Gabriel Genellina]

En Wed, 28 Feb 2007 19:09:09 -0300, sjdevnull at yahoo.com  
<sjdevnull at yahoo.com> escribió:

> On Feb 28, 11:24 am, Alan Franzoni
> <alan.franzoni_inva... at geemail.invalid> wrote:
>> Il 27 Feb 2007 16:14:20 -0800, sjdevn... at yahoo.com ha scritto:
>>
>> > Those mean different things:
>>
>> >>>> a=[1]
>> >>>> b=a
>> >>>> a += [2]
>> >>>> a
>> > [1, 2]
>> >>>> b
>> > [1, 2]
>> >>>> a=[1]
>> >>>> b=a
>> >>>> a = a + [2]
>> >>>> a
>> > [1, 2]
>> >>>> b
>> > [1]
>>
>> This is a really nasty one! I just answered to Tim above here, and then  
>> I
>> saw your example... I had never realized that kind of list behaviour.
>> That's probably because i never use + and += on lists (i prefer the more
>> explicit append() or extend() and i do copy list explictly when I want  
>> to)
>> , BTW I think this behaviour is tricky!
>
> Seems obvious and desirable to me.  Bare "=" is the way you assign a
> name to an object; saying "NAME =" will rebind the name, breaking the
> connection between a and b.  Without it, they continue to refer to the
> same object; extending the list (via += or .extend) mutates the
> object, but doesn't change which objects a and b are referencing.
>
> It would be very counterintuitive to me if "=" didn't change the
> name's binding, or if other operators did.

Note that a += b first tries to use __iadd__ if it is available, if not,  
behaves like a = a + b.
And even if __iadd__ exists, there is no restriction on it to mutate the  
object in place; it may return a new instance if desired.
So, a += b may involve a name rebinding anyway. Try the example above  
using immutable objects like tuples or strings.

-- 
Gabriel Genellina