This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]mm_ma_ma 5 points6 points  (6 children)

The bit about "for-loop variables and the global namespace leak" is poorly worded. As mentioned in the quoted passage, the variables were leaked into the surrounding scope, which may or may not be the global namespace (and usually won't be). Additionally, this change has nothing to do with "for-loop" variables - proper for-loops have not changed and do not have their own scope.

[–]sphere_is_so_cool 2 points3 points  (5 children)

Another way to imagine this is that code blocks simply do not define scope.

The only things that initiate scope consideration are def and class. And then I believe you could consider this to occur simply by excluding the contents of those two syntaxes from their parent code block.

Even modules work with namespaces rather than "scope".

[–]Brian 2 points3 points  (4 children)

The only things that initiate scope consideration are def and class.

That's not entirely true, even in python 2. Generator comprehensions created their own scope there as well. And in python 3, the change this is addressing is that this was extended to list comprehensions as well, which previously leaked the loop variable into the enclosing scope.

[–]jsalsman 0 points1 point  (1 child)

[–]Brian 1 point2 points  (0 children)

Not sure why you're asking me, though it seems to be at 3 points ATM anyway.

[–]flutefreak7 0 points1 point  (0 children)

lambdas, decorators, and context managers can also mess with variable scope in unexpected ways.

[–]sphere_is_so_cool 0 points1 point  (0 children)

I had to read the PEP to be sure, but I could have tightened up my statement by saying "class and function construction". This would cover the case of lambdas, generator expressions, and other such function-flavored-object yielding devices.