Re: Enhancing variable scope control

Barry wrote:
The ways scoping works in python is very hard to change as you are asking for i think was a major reason to reject.
Perhaps it isn't all that difficult; For instance, a "local:" declaration could be treated as if it were "def function()" with an immediately succeeding call as far as the interpreter is concerned. That buys the scoping for (nearly) free. We write... local: for MyVal in range(0,10) pass ...interpreter codes that, out of sight, as: def ghost_func_0000001(): for MyVal in range(0,10) pass ghost_func_0000001() Might take a bit of fiddling to make sure return and yield were appropriate [requiring an actual enclosing def function():], but other than that, it's basically the same idea -- provides scoping, making it easier for us to code, debug, and document, while significantly decreasing the likelihood of variable collisions. --Ben

On Wed, 30 Nov 2022 at 18:02, Anony Mous <fyngyrz@gmail.com> wrote:
That would make "return" in the local scope exit the scope, not the enclosing function. Which is almost certainly not what people would expect from a "local scope" statement. Paul

On Thu, 1 Dec 2022 at 05:03, Anony Mous <fyngyrz@gmail.com> wrote:
def local(f): return f() @local def _(): for MyVal in range(0, 10): pass Not sure what you mean about "mak[ing] sure return and yield were appropriate" though. Inside such a local block, are you expecting yield and return to apply to the outer function? If so, it would most definitely NOT be free for the interpreter to wrap it in a function, as this would require some completely new functionality. For a much, MUCH easier way to give semantics to this, here's a concept that I put together for re-scoping "except Exception as e:" a while back: the technical scoping rules remain exactly the same, but the variable name is mangled. This would be similar to how mangled names work in classes, and wouldn't require that the mangled names be legal Python identifiers. For instance, this hypothetical code: def foo(): e = 2.718281828 try: ... except local Exception as e: ... try: ... except local Exception as e: ... could be compiled to have local variables named "e", ".e.0", and ".e.1". As long as this occurs only at function scope, this has no impact on the normal running of the code other than the locals() dictionary (which would include all three variants, under those keys). However, I don't think this is a good idea. It would work, kinda, but it wouldn't be easy to describe, and that's usually a bad sign. Without variable declarations, it's not usually worth having infinitely nested scopes. ChrisA

On 1/12/22 6:58 am, Anony Mous wrote:
I'm not convinced it would be beneficial in Python. In C you have declarations that make it clear when you're introducing a new variable, but in Python there's nothing saying that MyVal has a restricted scope other than the rather inconspicuous "local:" above it. -- Greg

On Wed, 30 Nov 2022 at 18:02, Anony Mous <fyngyrz@gmail.com> wrote:
That would make "return" in the local scope exit the scope, not the enclosing function. Which is almost certainly not what people would expect from a "local scope" statement. Paul

On Thu, 1 Dec 2022 at 05:03, Anony Mous <fyngyrz@gmail.com> wrote:
def local(f): return f() @local def _(): for MyVal in range(0, 10): pass Not sure what you mean about "mak[ing] sure return and yield were appropriate" though. Inside such a local block, are you expecting yield and return to apply to the outer function? If so, it would most definitely NOT be free for the interpreter to wrap it in a function, as this would require some completely new functionality. For a much, MUCH easier way to give semantics to this, here's a concept that I put together for re-scoping "except Exception as e:" a while back: the technical scoping rules remain exactly the same, but the variable name is mangled. This would be similar to how mangled names work in classes, and wouldn't require that the mangled names be legal Python identifiers. For instance, this hypothetical code: def foo(): e = 2.718281828 try: ... except local Exception as e: ... try: ... except local Exception as e: ... could be compiled to have local variables named "e", ".e.0", and ".e.1". As long as this occurs only at function scope, this has no impact on the normal running of the code other than the locals() dictionary (which would include all three variants, under those keys). However, I don't think this is a good idea. It would work, kinda, but it wouldn't be easy to describe, and that's usually a bad sign. Without variable declarations, it's not usually worth having infinitely nested scopes. ChrisA

On 1/12/22 6:58 am, Anony Mous wrote:
I'm not convinced it would be beneficial in Python. In C you have declarations that make it clear when you're introducing a new variable, but in Python there's nothing saying that MyVal has a restricted scope other than the rather inconspicuous "local:" above it. -- Greg
participants (4)
-
Anony Mous
-
Chris Angelico
-
Greg Ewing
-
Paul Moore