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 <
stephenjturnb...@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-le...@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/BHMQ6VZL7WJP2H3CWP2B2LQH45FJZFJG/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/LKMB5OLQQHVBO2T7BXBVHU5PUNDMAMFU/
Code of Conduct: http://python.org/psf/codeofconduct/
