✨ Congrats Nick on your 100 emails thread 😍! ✨ You won a virtual piece of cake: 🍰 2018-06-22 16:22 GMT+02:00 Nick Coghlan <ncoghlan@gmail.com>:
On 22 June 2018 at 02:26, Antoine Pitrou <solipsis@pitrou.net> wrote:
Indeed. But, for a syntax addition such as PEP 572, I think it would be a good idea to ask their opinion to teaching/education specialists.
As far as I'm concerned, if teachers and/or education specialists were to say PEP 572 is not a problem, my position would shift from negative towards neutral.
I asked a handful of folks at the Education Summit the next day about it:
* for the basic notion of allowing expression level name binding using the "NAME := EXPR" notation, the reactions ranged from mildly negative (I read it as only a "-0" rather than a "-1") to outright positive. * for the reactions to my description of the currently proposed parent local scoping behaviour in comprehensions, I'd use the word "horrified", and feel I wasn't overstating the response :)
While I try to account for the fact that I implemented the current comprehension semantics for the 3.x series, and am hence biased towards considering them the now obvious interpretation, it's also the case that generator expressions have worked like nested functions since they were introduced in Python 2.4 (more than 13 years ago now), and comprehensions have worked the same way as generator expressions since Python 3.0 (which has its 10th birthday coming up in December this year).
This means that I take any claims that the legacy Python 2.x interpretation of comprehension behaviour is intuitively obvious with an enormous grain of salt - for the better part of a decade now, every tool at a Python 3 user's disposal (the fact that the iteration variable is hidden from the current scope, reading the language reference [1], printing out locals(), using the dis module, stepping through code in a debugger, writing their own tracing function, and even observing the quirky interaction with class scopes) will have nudged them towards the "it's a hidden nested function" interpretation of expected comprehension behaviour.
Acquiring the old mental model for the way comprehensions work pretty much requires a developer to have started with Python 2.x themselves (perhaps even before comprehensions and lexical closures were part of the language), or else have been taught the Python 2 comprehension model by someone else - there's nothing in Python 3's behaviour to encourage that point of view, and plenty of functional-language-inspired documentation to instead encourage folks to view comprehensions as tightly encapsulated declarative container construction syntax.
I'm currently working on a concept proposal at https://github.com/ncoghlan/peps/pull/2 that's much closer to PEP 572 than any of my previous `given` based suggestions: for already declared locals, it devolves to being the same as PEP 572 (except that expressions are allowed as top level statements), but for any names that haven't been previously introduced, it prohibits assigning to a name that doesn't already have a defined scope, and instead relies on a new `given` clause on various constructs that allows new target declarations to be introduced into the current scope (such that "if x:= f():" implies "x" is already defined as a target somewhere else in the current scope, while "if x := f() given x:" potentially introduces "x" as a new local target the same way a regular assignment statement does).
One of the nicer features of the draft proposal is that if all you want to do is export the iteration variable from a comprehension, you don't need to use an assignment expression at all: you can just append "... given global x" or "... given nonlocal x" and export the iteration variable directly to the desired outer scope, the same way you can in the fully spelled out nested function equivalent.
Cheers, Nick.
[1] From https://docs.python.org/3.0/reference/expressions.html#displays-for-lists-se...: 'Note that the comprehension is executed in a separate scope, so names assigned to in the target list don’t “leak” in the enclosing scope.' -- Nick Coghlan | ncoghlan@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/vstinner%40redhat.com