Re: [Python-Dev] just trying to catch up with the semantic
Hi. Your rationale sounds ok. We are just facing the oddities of the python rule - that assignment indetifies locals - when extended to nested scopes new world. (Everybody will be confused his own way ;), better write non confusing code ;)) I think I should really learn to read code this way, and also everybody coming from languages with explicit declarations: is the semantic (expressed through bytecode instrs) right? (I) from __future__ import nested_scopes x=7 def f(): #pseudo-local-decl x x=1 def g(): global x # global-decl x def i(): def h(): return x # => LOAD_GLOBAL return h() return i() return g() print f() print x (II) def g(): #pseudo-local-decl x x = 2 # instead of global def i(): def h(): return x # => LOAD_DEREF (x from g) return h() return i() (III) def g(): global x # global-decl x x = 2 # => STORE_GLOBAL def i(): def h(): return x # => LOAD_GLOBAL return h() return i() (IV) def f(): # pseudo-local-decl x x = 3 # => STORE_FAST def g(): global x # global-decl x x = 2 # => STORE_GLOBAL def i(): def h(): return x # => LOAD_GLOBAL return h() return i() (IV) def g(): global x # global-decl x x = 2 # => STORE_GLOBAL def i(): def h(): # pseudo-local-decl x x = 10 # => STORE_FAST return x # => LOAD_FAST return h() return i() If one reads also here the implicit local-decl, this is fine, otherwise this is confusing. It's a matter whether 'global' kills the local-decl only in one scope or in the nesting too. I have no preference. regards, Samuele Pedroni.
"SP" == Samuele Pedroni <pedroni@inf.ethz.ch> writes:
SP> If one reads also here the implicit local-decl, this is fine, SP> otherwise this is confusing. It's a matter whether 'global' SP> kills the local-decl only in one scope or in the nesting too. I SP> have no preference. All your examples look like what is currently implemented. My preference is that global kills the local-decl only in one scope. I'll stick with that unless Guido disagrees. Jeremy
Jeremy:
My preference is that global kills the local-decl only in one scope.
I agree, because otherwise there would be no way of *undoing* the effect of a global in an outer scope. The way things are, I can write a function def f(): x = 3 return x and be assured that x will always be local, no matter what environment I move the function into. I like this property. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
is the semantic (expressed through bytecode instrs) right?
Hi Samuele, Thanks for bringing this up. I agree with your predictions for these examples, and have checked them in as part of the test_scope.py test suite. Fortunately Jeremy's code passes the test! The rule is really pretty simple if you look at it through the right glasses: To resolve a name, search from the inside out for either a scope that contains a global statement for that name, or a scope that contains a definition for that name (or both). Thus, on the one hand the effect of a global statement is restricted to the current scope, excluding nested scopes: def f(): global x def g(): x = 1 # new local On the other hand, a name mentioned a global hides outer definitions of the same name, and thus has an effect on nested scopes: def f(): x = 1 def g(): global x def h(): return x # global We shouldn't code like this, but it's good to agree on what it should mean when encountered! --Guido van Rossum (home page: http://www.python.org/~guido/)
"GvR" == Guido van Rossum <guido@digicool.com> writes:
GvR> To resolve a name, search from the inside out for either GvR> a scope that contains a global statement for that name, or a GvR> scope that contains a definition for that name (or both). I think that's an excellent rule Guido -- hopefully it's captured somewhere in the docs. :) I think it yields behavior that both easily discovered by visual code inspection and easily understood. -Barry
[Barry A. Warsaw]
I think that's an excellent rule Guido --
Hmm. After an hour of consideration, I would agree, provided only that the rule also say you *stop* upon finding the first one <wink>.
hopefully it's captured somewhere in the docs. :)
The python-dev archives are incorporated into the docs by implicit reference. you-found-it-you-fix-it-ly y'rs - tim
That's quick -- it took me longer than that to come to the conclusion that Jeremy had actually done the right thing. :-)
I'm sure the docs can stand some updates after the 2.1b1 crunch is over to document what all we did. After the conference! --Guido van Rossum (home page: http://www.python.org/~guido/)
"SP" == Samuele Pedroni <pedroni@inf.ethz.ch> writes:
SP> If one reads also here the implicit local-decl, this is fine, SP> otherwise this is confusing. It's a matter whether 'global' SP> kills the local-decl only in one scope or in the nesting too. I SP> have no preference. All your examples look like what is currently implemented. My preference is that global kills the local-decl only in one scope. I'll stick with that unless Guido disagrees. Jeremy
Jeremy:
My preference is that global kills the local-decl only in one scope.
I agree, because otherwise there would be no way of *undoing* the effect of a global in an outer scope. The way things are, I can write a function def f(): x = 3 return x and be assured that x will always be local, no matter what environment I move the function into. I like this property. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
is the semantic (expressed through bytecode instrs) right?
Hi Samuele, Thanks for bringing this up. I agree with your predictions for these examples, and have checked them in as part of the test_scope.py test suite. Fortunately Jeremy's code passes the test! The rule is really pretty simple if you look at it through the right glasses: To resolve a name, search from the inside out for either a scope that contains a global statement for that name, or a scope that contains a definition for that name (or both). Thus, on the one hand the effect of a global statement is restricted to the current scope, excluding nested scopes: def f(): global x def g(): x = 1 # new local On the other hand, a name mentioned a global hides outer definitions of the same name, and thus has an effect on nested scopes: def f(): x = 1 def g(): global x def h(): return x # global We shouldn't code like this, but it's good to agree on what it should mean when encountered! --Guido van Rossum (home page: http://www.python.org/~guido/)
"GvR" == Guido van Rossum <guido@digicool.com> writes:
GvR> To resolve a name, search from the inside out for either GvR> a scope that contains a global statement for that name, or a GvR> scope that contains a definition for that name (or both). I think that's an excellent rule Guido -- hopefully it's captured somewhere in the docs. :) I think it yields behavior that both easily discovered by visual code inspection and easily understood. -Barry
[Barry A. Warsaw]
I think that's an excellent rule Guido --
Hmm. After an hour of consideration, I would agree, provided only that the rule also say you *stop* upon finding the first one <wink>.
hopefully it's captured somewhere in the docs. :)
The python-dev archives are incorporated into the docs by implicit reference. you-found-it-you-fix-it-ly y'rs - tim
That's quick -- it took me longer than that to come to the conclusion that Jeremy had actually done the right thing. :-)
I'm sure the docs can stand some updates after the 2.1b1 crunch is over to document what all we did. After the conference! --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (6)
-
barry＠digicool.com -
Greg Ewing -
Guido van Rossum -
Jeremy Hylton -
Samuele Pedroni -
Tim Peters