On 2006-07-09, Piet van Oostrum <[EMAIL PROTECTED]> wrote: >>>>>> Antoon Pardon <[EMAIL PROTECTED]> (AP) wrote: > >>AP> It is conceptually different. In the line 'a = b' you don't need to >>AP> search for the scope of a. You know it is the current scope, if you > > Except when it has been declared global.
Yes, I ignored that possibilitym because as far as I understood we were discussing variables in intermediate scopes. >>AP> want to know the scope of b on the other hand, you need to search >>AP> for statement where it is assigned to. > >>AP> Sure you can set things up in the interpreter so that the same search >>AP> routine is used, but that is IMO an implementation detail. > >>>> Well, it is not. But I can understand the >>>> confusion. Namely, `a = b' introduces a binding for `a' in the local scope, >>>> unless `a' was declared global. So the search will find `a' in the local >>>> scope and it stops there. On the other hand `a.b = c' will not introduce a >>>> binding for `a'. So the search for `a' may stop in the local space (if >>>> there was another binding for `a' in the local scope) or it may need to >>>> continue to outer scopes. The difference, however is not the >>>> complicatedness of the lefthand side but whether the local scope contains a >>>> binding for the variable. > >>AP> The complicatedness of the lefthand side, decided on whether the >>AP> variable was introduced in the local scope or not during startup >>AP> time. So that complicatedness decided whether the search was >>AP> to stop at the local level or not. > No, it doesn't. There could be another binding in the same scope. Indeed there could be. But I hoped you would understand I was just keeping things simple, with a simple example. > The > complicatedness of this particular assignment doesn't decide anything about > how to search for 'a', but rather the presence or absence of a binding > anywhere in the scope. I'll word it differently. If the compiler encounters a line like 'a = b' then you know from that line alone that the search space for a will be limited to the local scope. If you encounter a line like 'a.c = b' then you have no such knowledge. A line like 'a = b' will cause the compilor that at call time variable a will be added to the local scope, a line like 'a.c = b' will not have that effect. So a line like 'a = b' has an influence on what the search space is for variable a, while a line like 'a.c = b' doesn't. So the complicatedness on the leftside decides whether or not the compilor will take certain actions with regards to the search space of the variable on the left side. And yes I'm again ignoring global. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
