With PEP 572's formal acceptance now expected to be just a matter of time, I'll limit any further personal expressions of opinion on the change and the process taken to achieve it to other venues :)
However, there's a design aspect I do need to address, which is to make sure that PEP 558 (my proposal to actually nail down an implementation independent specification for how we expect locals() to behave at runtime) accurately covers the way runtimes and debuggers are expected to behave when comprehensions and generator expressions are executed at different scopes. My current view is that it's going to be OK to expose the differing behaviours at module and function scope directly: * if you debug a module level comprehension or genexp, the target name will be flagged on the code object as a dynamically resolved name reference, so a debugger should handle it the same was as it would handle any other "global NAME" declaration (and it will appear only in globals(), not in locals()) * similarly for a function comprehension or genexp, the name will show up like any other "nonlocal NAME" (appears in locals() rather than globals(), and is affected by the proposed changes in the interaction between trace functions and the frame.f_locals attribute) I think that's an acceptable outcome, since it's a natural consequence of PEP 572 defining its comprehension and generator expression handling in terms of existing global and nonlocal scoping semantics. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
