[Python-Dev] PEP 572: Assignment Expressions (original) (raw)

Kirill Balunov kirillbalunov at gmail.com
Sun Apr 22 07:10:48 EDT 2018

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>

More information about the Python-Dev mailing list