On 19 April 2018 at 02:38, Brett Cannon wrote:

I'm also -1.

I understand the usefulness of the construct in languages where block scopes make having this kind of expression assignment in e.g. an 'if' guard useful. But for Python and it's LGB scoping -- although I think we need to add an "N" for "non-local" :) -- this is syntactic sugar and I don't see enough wide benefit on top of the potential ugliness/misuse of it to warrant the cognitive overhead of adding it.

Although, as usual, Chris, great PEP! :)

Aye, tremendous work on the PEP Chris - assignment expressions are an idea that has come up many, many times on python-ideas, and it's great to finally have a consolidated proposal that attempts to make the best case it can for the idea. Unfortunately, I still have to admit that even I'm -0 on the idea of actually adding it to the language (despite helping it to reach a plausibly acceptable state), primarily on "more than one way to do it" grounds: * assignment statements and top-level assignment expressions would be syntactically distinct, but semantically identical * for the if statement use case, pre-assignment of the re-used part of the condition expression already works fine * for the while loop use case, I think my discussion with Tim about tuple unpacking shows that the loop-and-a-half construct won't be going anywhere, so users would still end up needing to learn both forms (even for new code) The comprehension/genexp use case still seems like the most promising candidate for a reasonable justification for the extra complexity, but there's also a solid argument that if a comprehension is complex enough that the lack of assignment expressions is causing problems, then it's also complex enough that it's reasonable to require extracting the algorithm into a named generator function in order to access assignment statements. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia