(status := "Accepted") and "Congratulations!" ;-) (hope I did that right, but I can't try it yet!) Thanks for hanging in there, Guido, and for your patience with everyone during the discussions. I'm glad you're still with us! --Chris On Wed, Jul 11, 2018 at 5:10 PM, Guido van Rossum wrote:

As anticippated, after a final round of feedback I am hereby accepting PEP 572, Assignment Expressions: https://www.python.org/dev/peps/pep-0572/

Thanks to everyone who participated in the discussion or sent a PR.

Below is a list of changes since the last post ( https://mail.python.org/pipermail/python-dev/2018-July/154557.html) -- they are mostly cosmetic so I won't post the doc again, but if you want to go over them in detail, here's the history of the file on GitHub: https://github.com/python/peps/commits/master/pep-0572.rst, and here's a diff since the last posting: https://github.com/python/peps /compare/26e6f61f...master (sadly it's repo-wide -- you can click on Files changed and then navigate to pep-0572.rst).

- Tweaked the example at line 95-100 to use result = ... rather than return ... so as to make a different rewrite less feasible - Replaced the weak "2-arg iter" example with Giampaolo Roloda's while chunk := file.read(8192): process(chunk) - *Added prohibition of unparenthesized assignment expressions in annotations and lambdas* - Clarified that TargetScopeError is a *new* subclass of SyntaxError - Clarified the text forbidding assignment to comprehension loop control variables - Clarified that the prohibition on := with annotation applies to *inline* annotation (i.e. they cannot be syntactically combined in the same expression) - Added conditional expressions to the things := binds less tightly than - Dropped section "This could be used to create ugly code" - Clarified the example in Appendix C

Now on to the implementation work! (Maybe I'll sprint on this at the core-dev sprint in September.)

-- --Guido van Rossum (python.org/~guido)

_______________________________________________ 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/ chris.jerdonek%40gmail.com

On Fri, Jul 13, 2018 at 11:36 PM, Random832 wrote:

On Wed, Jul 11, 2018, at 20:10, Guido van Rossum wrote:

...

As anticippated, after a final round of feedback I am hereby accepting PEP 572, Assignment Expressions: https://www.python.org/dev/peps/pep-0572/

I know everyone else is probably sick of discussing this (I somehow completely missed the discussion until it was almost done) but I have a question...

Why does this not allow assignment to attributes and subscripts? I think this is, at least, surprising enough that there should be a rationale section explaining it in the PEP. As it is, it's barely even explicitly stated, other than the use of 'NAME' in a few places and an offhand mention "and [the assignment statement] can assign to attributes and subscripts."

It was discussed at some length, yes. Assignment to arbitrary targets would also mean permitting iterable unpacking, which is not desired ("x, y := 3, 4"??), and there weren't enough use-cases for attribute/item assignment to justify creating a rule of "you can assign to any single target, but can't unpack". In the future, if such use-cases are found, the grammar can be expanded. ChrisA

On 13 July 2018 at 23:36, Random832 wrote:

On Wed, Jul 11, 2018, at 20:10, Guido van Rossum wrote:

...

As anticippated, after a final round of feedback I am hereby accepting PEP 572, Assignment Expressions: https://www.python.org/dev/peps/pep-0572/

I know everyone else is probably sick of discussing this (I somehow completely missed the discussion until it was almost done) but I have a question...

Why does this not allow assignment to attributes and subscripts? I think this is, at least, surprising enough that there should be a rationale section explaining it in the PEP. As it is, it's barely even explicitly stated, other than the use of 'NAME' in a few places and an offhand mention "and [the assignment statement] can assign to attributes and subscripts."

It's in the same category as disallowing assignment to attributes and subscripts in other name binding operations like "def" and "class" statements: there isn't a technical limitation preventing it, there's a design decision that we currently believe allowing it would reduce code clarity rather than increase it. It's also the case that unlike local name bindings, assigning to attributes and subscripts as an expression can already be formulated as a helper function with side effects. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia