Antoon Pardon wrote: > On 2006-07-06, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote: > >>Antoon Pardon wrote: >> >>>On 2006-07-05, Piet van Oostrum <[EMAIL PROTECTED]> wrote: >>> >>> >>>>>>>It's not about "finding a name/identifier", it's about the difference >>>>>>>between (re)binding a name and mutating an object. >>>> >>>>>AP> The two don't contradict each other. Python has chosen that it won't >>>>>AP> rebind variables that are out of the local scope. So if the lefthand >>>>>AP> side of an assignment is a simple name it will only search in the >>>>>AP> local scope for that name. But if the lefthand side is more complicated >>>>>AP> if will also search the outerscopes for the name. >> >>Now it's pretty clear you *don't* understand. >> >>In the second case, ie: >> >>k = [0] >>def f(i): >> k[0] += i >> >>'k[0]' is *not* a name. The name is 'k'. If we rewrite this snippet >>without all the syntactic sugar, we get something like: >> >>k = [0] >>def f(i): >> k.__setitem_(0, k.__getitem__(0) + i) >> >>Now where do you see any rebinding here ? > > > What point do you want to make? As far as I can see, I > didn't write anything that implied I expected k to > be rebound in code like
Please re-read your own writing above. > > k[0] += i > > So why are you trying so hard to show me this? > I was just expecting to be of any help, but it seems you just *refuse* to understand. >>>>No. It will always use the same search order. >>> >>> >>>So if I understand you correctly in code like: >>> >>> c.d = a >>> b = a >>> >>>All three names >> >>which ones ? >> >> >>>are searched for in all scopes between the local en global >>>one. >> >>In this example, we're at the top level, so the local scope is the >>global scope. I assert what you meant was: > > > I'm sorry I should have been more clear. I meant it to be > a piece of function code. > > >>c = something >>a = something_else >> >>def somefunc(): >> c.d = a >> b = a >> >>(NB : following observations will refer to this code) >> >> >>>That is what I understand with your statement that [python] always >>>uses the same search order. >> >>yes. >> >> >>>My impression was that python will search for c and a in the total current >>>namespace >> >>what is "the total current namespace" ? >> I still wait your explanation on this... >>>but will not for b. >> >>b is bound in the local namespace, so there's no need to look for it in >>enclosing namespaces. > > > Now could you clarify please. First you agree with the statement that python > always uses the same search order, Yes : local namespace, then enclosing namespaces. > then you state here there is no need > to look for b because it is bound to local namespace. Yes. b being bound in the local namespace, it's found in the local namespace, so lookup stops here. Pretty simple. > That seems to > imply that the search order for b is different. cf above. > AFAIR my original statement was that the search for b was different than > the search for a; And it's plain wrong, as anyone taking a few minutes reading the doc and doing some tests would know. > meaning that the search for b was limited to the local > scope and this could be determined from just viewing a line like "b = a" > within a function. The search for a (or c in a line like: "c.d = a") > is not limited to the local scope. Please repeat after me : 1/ binding in the local namespace makes the name local 2/ search order is local namespace first, then enclosing namespaces. > I may see some interpretation where you may say that the search order > for b is the same as for a and c There's nothing to "interpret" here. > but I still am not comfortable with > it. Too bad for you. But whether you are "comfortable" with reality is none of my concern. > >>>>But a variable that is bound >>>>inside the function (with an asignment) and is not declared global, is in >>>>the local namespace. >>> >>> >>>Aren't we now talking about implementation details? >> >>Certainly not. Namespaces and names lookup rules are fundamental parts >>of the Python language. > > > I don't see the contradiction. So go and get yourself some glasses. > That Namespaces and names lookup are > fundamentel parts of the Python language, doesn't mean that > the right behaviour define "right behaviour" ? > can't be implemented in multiple ways I don't give a damn about how it's implemented. > and > doesn't contradict that a specific explanation depend on a specific > implementation instead of just on language definition. > This is totally meaningless. >>>Sure the compilor >>>can set things up so that local names are bound to the local scope and >>>so the same code can be used. But it seems somewhere was made the >>>decision that b was in the local scope without looking for that b in >>>the scopes higher up. >> >>binding creates a name in the current namespace. b is bound in the local >>namespace, so b is local. period. > > I wrote nothing that contradicts that. I give up. You're a crank. -- bruno desthuilliers python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for p in '[EMAIL PROTECTED]'.split('@')])" -- http://mail.python.org/mailman/listinfo/python-list