[Python-Dev] PEP 572: Assignment Expressions

[Kirill Balunov]

2018-04-21 4:44 GMT+03:00 Tim Peters <tim.peters at gmail.com>:

> [Chris Angelico <rosuav at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180422/ec9227cb/attachment.html>