On 2 March 2018 at 14:23, Nick Coghlan email@example.com wrote:
On 2 March 2018 at 23:26, Paul Moore firstname.lastname@example.org wrote:
Adding "mustn't just be another way to spell name = expr" to the requirements is an extra requirement - and arguably one that contradicts the original requirement which was "find a way to allow name = expr in expressions".
I consider allowing the semantic equivalent of "name = expr" as part of arbitrary expressions to be an anti-requirement, not a requirement, for three reasons:
- It means that arbitrary statements may accidentally clobber local
variables that we care about. We used to have this for comprehension iteration variables, and it was so widely deplored that we broke compatibility with the variable overwriting behaviour in Python 3.0.
- It means that naming a subexpression may significantly increase the
longevity of that reference (especially in generators and coroutines).
- It means that naming a subexpression will define a new class or module
attribute when used in a class or module scope
Folks do sometimes *ask* for these semantics, as it's the most obvious behaviour to ask for when it comes to naming subexpressions, but it would be a really bad idea to say "yes" to those requests.
Chris's PEP addresses all those potential problems:
- Statement locals explicitly avoid overwriting regular function locals
(although they may shadow them in the current PEP - the '.name' syntax avoids even that) 2. Statement local bindings are cleared after each statement, so they only significantly extend the reference lifespan when used in compound statement headers or directly in the same statement as a yield or await. Even in comprehensions they'll typically be cleared on the next loop iteration. 3. Statement locals aren't added to locals() or globals(), so they never show up as module or class attributes either
The eventual conclusion may still be "The proposal adds too much additional complexity without an adequate corresponding gain in expressiveness", but that complexity does have a solid rationale behind it. (Although it may be worth explicitly answering "Why not use the exact same semantics as 'name = expr'? in the PEP itself, since it's a reasonable question to ask)
Yes, I think it would be worth adding that question to the PEP. I also think it would be worth being more explicit in the body of the PEP over how the binding of statement-local names is fundamentally different from assignment, as that certainly wasn't obvious to me, and may not be to others (particularly people reading it with the point of view "This satisfies my request to allow assignment in expressions").
I don't really have much more to add in that case. I don't personally think the added complexity is justified by the benefits, but I've already said that and it's been noted - so thanks for helping me understand the details of the proposal better, but it hasn't changed my view much in the end.
 The "why" is covered by the question you suggested.