2018-04-21 4:44 GMT+03:00 Tim Peters <tim.peters@gmail.com>:
[Chris Angelico <rosuav@gmail.com>]
> I don't see much value in restricting the assignment target to names
> only, but if that's what it takes, it can be restricted, at least
> initially.

I believe this point was made most clearly before by Terry Reedy, but
it bears repeating :-)  This is from the PEP's motivation:

"""
Naming the result of an expression is an important part of
programming, allowing a descriptive name to be used in place of a
longer expression, and permitting reuse.
"""

As "head arguments" go, that's a good one!  But restricting assignment
expressions to

    identifier ":=" expression

satisfies it.  If what's of value is to name the result of an
expression, that single case handles that and _only_ that.  In a
sense, it's "the simplest thing that could possibly work", and that's
generally a good thing to aim for.

Python assignment _statements_ are way more complex than that.
Besides just giving names to expression results, they can also
implicitly invoke arbitrarily complex __setitem__ and __setattr__
methods on targets, rely on all sorts of side effects across chained
assignments, and support funky syntax for magically iterating over an
expression's iterable result.

While that can all be useful _in_ an assignment statement, the PEP's
motivation doesn't say a word about why any of _that_ would also be
useful buried inside an assignment expression.  There doesn't appear
to be a good "head argument" for why, besides "why not?".  That's not
enough.

I agree with you. During the discussion on python-ideas there was not explicitly suggested to limit assignment target to name only but that was often implicitly implied. So explicit is better than implicit :) The main reason for such criticism was related to the fact that almost all of the examples from the PEP use `name := expression` form. Also it was noted that 99% of use-cases where this feature will be _nice_ to have is `while` and `if` statements (including ternary from). Although one of the prerequisites for writing this PEP was the use of the assignment expression in the lists, it will rarely be used in them, and even more rarely it will be a justified usage of. In addition, in the case of the general assignment expression and the chosen operator `: =`, which solves the problem of distinctness from `==`, I see no reason, or more precisely how to explain, why will not other forms `+=`, `*=`  become expressions either? And then we are faced with with all the beauty of side effects, sequnce points,  ... And while in Python it's much easier to resolve this - Python will no longer be Python. I'm glad that this does not happen.

Since the discussion moves towards a simplified form - `binding expression`, where assignment target can be name only. Will you be _happy_ with the choice of `:=` operator?  Which is perceived as `=`, but with very limited capabilities. Therefore, as I see it, with this _limited power_ it is one of design goals to make the syntax forms of `assignment statement` and `assignment expression` to be distinct and `:=` does not help with this. This does not mean that this new syntax form should not be convenient, but it should be different from the usual `=` form. Otherwise, the question about  ".1 + .2" will have competitors :-)

 
I think it's no coincidence that every example of an _intended_ use is
of the simple

    identifier ":=" expression

form. There are no examples of fancier targets in the PEP, and - more
importantly - also none I saw in the hundreds of mailing-list messages
since this started.  Except for a few of mine, where I tried to
demonstrate why _trying_ fancier targets in examples derived from real
code made the original "loop and a half" code _worse_  And where other
people were illustrating how incomprehensibly code _could_ be written
(which isn't a real interest of mine).


With kind regards,
-gdg