On 2006-07-07, Terry Reedy <[EMAIL PROTECTED]> wrote: > > "Antoon Pardon" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >> And if Nested variables are harmfull, > > I don't know if anyone said that they were, but Guido obviously does not > think so, or he would not have added them. So skip that. > >> what is then the big difference between rebinding them and mutating them > > A variable is a name. Name can be rebound (or maybe not) but they cannot > be mutated. Only objects (with mutation methods) can be mutated. In other > words, binding is a namespace action and mutation is an objectspace action. > In Python, at least, the difference is fundamental. > > Or, in other other words, do not be fooled by the convenient but incorrect > abbreviated phrase 'mutate a nested variable'.
I'm not fooled by that phrase. I just think the mutate vs rebind explanation is not complete. If we have two statements "a = b" and "c.d = b" the fact that a is being rebound while c is mutated doesn't explain why we allow c to be searched out of the local scope. By only stating that the first statement is a rebinding and the second is a mutation and that this is a fundamental difference in python you seem to suggest that this fundamental differenence implies this difference in searching scopes. Python could have made the choice that in an assignment the variable on the left side was always to be searched in local space so that code like the following would throw: UnboundLocalError: local variable 'c' referenced before assignment c = SomeObject def f(): c.a = 5 Now I'm not arguing python should have made this choice. But the possibility shows IMO this has more to do with search policies of names than with the distinction between a rebinding and a mutation. AFAIK when nested scopes where introduced everyone agreed that scopes had to have access to outer scopes. There were voices that supported allowing a rebinding in an outer scope but no consensus on how to do this was reached, so this possibility was dropped. So we can't rebind an outer scope variable but we can mutate such a variable because for mutation we only need access. >> I understand that python evolved and that this sometimes results >> in things that in hindsight could have been done better. > > So does Guido. That is one explicit reason he gave for not choosing any of > the nunerous proposals for the syntax and semantics of nested scope write > access. In the face of anti-consensus among the developers and no > particular personal preference, he decided, "Better to wait than roll the > dice and make the wrong, hard to reverse, choice now". (Paraphrased quote) > >>I have to wonder if someone really thought this through at design time > > Giving the actual history of, if anything, too many people thinking too > many different thoughts, this is almost funny. Maybe I didn't made myself clear enough, but I never meant to imply people hadn't thought thouroughly about this. If I gave you this impression I appologize. What I was wondering about was that those that had thought about it, would have reached a certain conclusion that seemed suggested. > Recently however, Guido has rejected most proposals to focus attention on > just a few variations and possibly gain a consensus. So I think there is > at least half a chance that some sort of nested scope write access will > appear in 2.6 or 3.0. Well I have browsed the discussion, which is why I react so lately to this, and there is one thing I wonder about. As far as I can see no suggestion removes the difference in the default search. The following code will still work and won't need an outer statement. (or global, nonlocal or whatever it will be) c = SomeObject def f(): c.a = 5 I don say they have to change this, but since it seemed decided this was a python3k thing, i think the question deserved to be raised. But I'm glad with this turn of events anyhow. Just my 2 cent. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list