[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é _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
