On 25 June 2018 at 13:17, Nick Coghlan <ncoghlan at gmail.com> wrote: > On 25 June 2018 at 09:25, Guido van Rossum <guido at python.org> wrote: >> A "neutral" argument about (b) is that despite the "horrified" reactions >> that Nick saw, in practice it's going to confuse very few people (again, due >> to my point about Python's scope rules). I'd wager that the people who might >> be most horrified about it would be people who feel strongly that the change >> to the comprehension scope rules in Python 3 is a big improvement, and who >> are familiar with the difference in implementation of comprehensions (though >> not generator expressions) in Python 2 vs. 3. > > FWIW, the most cryptic parent local scoping related exception I've > been able to devise so far still exhibits PEP 572's desired "Omitting > the comprehension scope entirely would give you the same name lookup > behaviour" semantics: > > >>> def outer(x=1): > ... def middle(): > ... return [x := x + i for i in range(10)] > ... return middle() > ... > >>> outer() > Traceback (most recent call last): > ... > NameError: free variable 'x' referenced before assignment in enclosing scope > > It isn't the parent local scoping, or even the assignment expression, > that's at fault there, since you'd get exactly the same exception for: > > def outer(x=1): > def middle(): > x = x +1 > return x > return middle() > Once again offering an "intuition" based response: 1. That definition of outer() is very complicated, I don't *expect* to understand it without checking the details. So the NameError is simply "hmm, wonder what triggered that?" not "OMG that's not what I'd expect!" :-) 2. Given that your version with no assignment expression or comprehension exhibits the same behaviour, I'm not sure what your argument is here anyway... Paul
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4