One of the few things I don't like about Python is that variable scope continues after the end of the suite the variable was created in --- probably because I think of local variable declarations as equivalent to lambdas that are called immediately, which works for most modern programming languages as well as for the theory. For example, it bugs me that you can write: if a: b = f(x) else: b = g(y) and get the same variable 'b' from it in the lines of code following that, regardless of which path was taken. I think a way to address this that would be more compatible with Python's style would be to add a new declaration syntax, perhaps borrowing from other languages and using the keyword 'let' where the variable is first assigned (and the rest of the assignment / declaration being as before). The variables declared this way would exist up to the end of the suite in which they were declared; there would be no need for any further syntax to delimit the scope. This would be fully forward-compatible, and those like me who don't like the existing scope rule could personally regard the old way of creating variables as deprecated. It would be easy for those coming to Python from various other popular languages, and I don't think it would be confusing to those learning Python as their first programming language --- the teacher / course writer could just pick either and stick with it. John On Mon, Jan 17, 2022 at 10:18 AM Stephen J. Turnbull < stephenjturnbull@gmail.com> wrote:
Iyad Ahmed writes:
Example use cases:
- Loop variables and similar, it is sometimes more comfortable to scope it to the loop body only - Not having to name variables var1, var2, var3, or makeup unnecessarily unique variable names, in some situations
I am not authoritative, so don't take this as a denial of the idea, but I want to give you some idea of why I suspect it is unlikely to succeed.
1. Python has a well-defined notion of *suites*, ie, indented groups of statements. If this were going to happen, I would imagine that it would be at the statement level, and most likely the syntax would be something like "block:" or "scope:" followed by an indented suite. (This is a quibble about syntax, not a reason it would be opposed in principle.) 2. Many statements in Python have suites, but only class and def create scopes. This is by design. It makes the rules for scopes simple. Since they can be used anywhere a statement can go, you can use them to create scopes (at the cost of having to invoke them later, of course). The exceptional case is that comprehensions have been changed to not leak their iteration variables, but this is basically done by implicitly defining and calling a function to create the scope if I remember correctly. 3. It's often useful to refer to the loop variable after exiting a loop. For example, if there's an explicit break in a loop controlled by a range or list, the loop variable tells you how far you got before exiting. I doubt a proposal to "close" the scope of the loop variable would be accepted. 4. It's generally considered bad style to have very long or deeply indented function bodies. Variable name collisions are more likely with global variables than with other variables in the same local scope. Perhaps for this reason, Python programmers don't frequently request more scopes. Again, the exception was the change in comprehension semantics mentioned above. which was a pain point for many. Programmers tend to think of displays more as "variable literals" than as "open-coded constructors", and therefore expect the scope to be closed.
Again, I'm not authoritative, but my recommendation is to consider the above points carefully while advocating this idea.
Steve _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/BHMQ6V... Code of Conduct: http://python.org/psf/codeofconduct/