On Tue, Apr 17, 2018 at 6:26 PM, Chris Jerdonek <chris.jerdo...@gmail.com> wrote: > On Tue, Apr 17, 2018 at 12:46 AM, Chris Angelico <ros...@gmail.com> wrote: >> >> Having survived four rounds in the boxing ring at python-ideas, PEP >> 572 is now ready to enter the arena of python-dev. I'll let the >> proposal speak for itself. Be aware that the reference implementation >> currently has a few test failures, which I'm still working on, but to >> my knowledge nothing will prevent the proposal itself from being >> successfully implemented. > > Very interesting / exciting, thanks! > >> Augmented assignment is not supported in expression form:: >> >> >>> x +:= 1 >> File "<stdin>", line 1 >> x +:= 1 >> ^ >> SyntaxError: invalid syntax > > Can you include in the PEP a brief rationale for not accepting this > form? In particular, is the intent never to support it, or is the > intent to expressly allow adding it at a later date (e.g. after > getting experience with the simpler form, etc)?
Sure. There are a few reasons; and Imaybe the best place to explain them is in the rejecteds section. Augmented assignment is currently all of these: augassign: ('+=' | '-=' | '*=' | '@=' | '/=' | '%=' | '&=' | '|=' | '^=' | '<<=' | '>>=' | '**=' | '//=') I'm actually not sure whether the augmented-assignment-expression operators should be "+:=" or ":+=", but either way, it'd be another thirteen tokens, some of which would be *four* character tokens. That's an awful lot of extra tokens. There's a lot less value in chaining on top of a "+=" than a simple assignment, and it doesn't seem right to have tons of code to support that. (Consider how much extra code there is to support async functions, and then imagine that you have a similarly large amount of effort for something that's of far lesser significance.) Another reason is that it can be confusing (to a human, not to the parser) that it would be the result of the augmented assignment, not the original expression, that would carry through. With regular assignment (whether it's to a simple name or to a subscript/attribute), removing the "target :=" part will leave you with the same value - the value of "x := 1" is 1. With augmented, the only logical way to do it would be to re-capture the left operand. Consider: x = 5 print(x +:= 2) Logically, this has to set x to 7, then print 7. But in more complicated situations, it can get confusing more easily than direct assignment does. Consider, for instance, augmented addition on a list, or similar. It could potentially be added later, but I'm not working hard to keep the option open or anything. Basically it's just "outside the scope of this document". ChrisA _______________________________________________ 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