[Python-Dev] assignment expressions: an alternative proposal

[Nick Coghlan]

On 25 April 2018 at 00:23, Yury Selivanov <yselivanov.ml at gmail.com> wrote:
> A lot of other questions arise though.  PEP 572 proposes:
>
> a = 1  # assignment
> a := 1  # also assignment
> (a := 1)  # also assignment
> (a = 1)  # error, why?

That's just the typical assignment/expression dichotomy, though, which
is genuinely confusing for learners (since expression-level Python and
statement-level Python allow different constructs), but also not a new
problem.

All the other keywords that have both statement level and expression
level use cases are structured as prefix operators in statement form,
and some kind of infix operator in expression form, whereas this would
be the first case where we offered a construct that used infix syntax
for both its statement form and its expression form.

> It's also difficult to explain which one to use when.  The net result
> is that code will be littered with both at random places.  That will
> decrease the readability of Python code at least for some users who
> have similar taste to myself.

That's a legitimate concern with PEP 572 (and part of why I'm
somewhere between -1 and -0 on the ":=" spelling, although I'd be +0
on an "is=" spelling that riffs off the "is" comparison operator -
using the "name is= expr" spelling in place of a regular assignment
looks sufficiently odd that I'd expect the temptation to write it in
place of "name = expr" when the latter is permitted would be low)

> With '=' in expressions, the code will look uniform.  There will be a
> simple rule to put parens around assignments in expression and use
> simple names.  After one or two descriptive SyntaxError users will
> learn how this syntax works (like people learn everything in coding).

Except that they'll also find other discrepancies like:

a = 1
a = 2

being OK, while:

a = 1
(a = 2)

fails with SyntaxError on the second line.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia