This thread is dead.

On Tue, Mar 27, 2018 at 5:40 PM, Rob Cliffe via Python-ideas <> wrote:

On 28/03/2018 01:19, Steven D'Aprano wrote:
On Wed, Mar 28, 2018 at 12:08:24AM +0100, Rob Cliffe via Python-ideas wrote:
On 27/03/2018 16:22, Guido van Rossum wrote:
The standard reply here is that if you can't tell at a glance whether
that's the case, your code is too complex. The Zen of Python says
"Namespaces are one honking great idea -- let's do more of those!" and
in this case that means refactor into smaller namespaces, i.e.

This is not always satisfactory.  If your for-loop uses 20
already-defined-locals, do you want to refactor it into a function with
20 parameters?
The standard reply here is that if your for-loop needs 20 locals, your
function is horribly over-complex and you may need to rethink your

And if you don't think "20 locals" is too many, okay, how about 50? 100?
1000? At some point we'll all agree that the function is too complex.

We don't have an obligation to solve every problem of excess complexity,
especially when the nominal solution involves adding complexity

For 25 years, the solution to complex functions in Python has been to
refactor or simplify them. That strategy has worked well in practice,
not withstanding your hypothetical function.

If you genuinely do have a function that is so highly coupled with so
many locals that it is hard to refactor, then you have my sympathy but
we have no obligation to add a band-aid for it to the language.
It's a fact of life that some tasks *are* complicated.  I daresay most aren't, or don't need to be, but some are.

Putting the loop variable in its own scope doesn't do anything about the
real problem: you have a loop that needs to work with twenty other local
variables. Any other modification to the loop will run into the same
problem: you have to check the rest of the function to ensure you're not
clobbering one of the twenty other variables. Special-casing the loop
variable seems hardly justified.

If there is a justification for introducing sub-local scoping, then I
think it needs to be something better than pathologically over-complex

But putting the loop variable in its own scope solves one problem: it ensures that the variable is confined to that loop, and you don't have to worry about whether a variable of the same name occurs elsewhere in your function.  In other words it increases local transparency (I'm not sure that's the right phrase, but I'm struggling to bring a more appropriate one to mind) and hence increases readability.
(I understand your point about being able to inspect the for-loop variable after the for-loop has terminated - I've probably done it myself - but it's a matter of opinion whether that convenience outweighs the cleanliness of confining the for-variable's scope.)
Rob Cliffe

Python-ideas mailing list
Code of Conduct:

--Guido van Rossum (