[Python-Dev] Explicit Lexical Scoping (pre-PEP?)

Boris Borcic bborcic at gmail.com
Fri Jul 14 15:46:26 CEST 2006


[Fredrik Lundh]
>>>>
>>>>       def counter(num):
>>>>           num = mutable_int(num)
>>>>           def inc():
>>>>               num += 1
>>>>               return num
>>>>           return inc
>>
>> feel free to replace that += with an .add(1) method call; the point
>> wasn't the behaviour of augmented assigment, the point was that that the
>> most common use pattern involves *mutation* of the target object.
>>
>> the syntax isn't that important, really.

No it isn't, but I believe it deserves notice that it's easy enough, currently, 
to mock your mutable_int replacing the "+=" by a simple "+", while the "+=" 
itself is not possible even though it reflects the intention more precisely.

[Jeremy Hylton]
> 
> Mutation is different from rebinding.A tuple is immutable, but you
> can rebind the variable that refers to the tuple. 

It's more than just rebinding, it's rebinding to a function of the currently 
bound value. And /that/ has clear features in common with mutation (witness most 
of the current semantics and implementation of augmented assignments, ie, how 
much and far it manages to postpone the decision as to which is actually the case).

 > I think we will
> confuse users if we use the term mutation to refer to name binding.
> Name binding is already a subtle issue, so I think the risk is
> significant.

I'd tend to agree, but imho there is a complementary risk of propagating 
confusion by denying what augmented assignments clearly show : that rebinding to 
a function of the currently bound value has so much in common with mutation that 
augmented assignments allow to confuse both cases in source code. Except for the 
scoping issue under discussion, that is.

Cheers, BB
--
"C++ is a contradiction in terms" - Lorentz, Einstein, Poincaré



More information about the Python-Dev mailing list