[Python-Dev] PEP 572: Assignment Expressions

[David Mertz]

It's horrors like this:

    g(items[idx] := idx := f())

That make me maybe +0 if the PEP only allowed simple name targets, but
decisively -1 for any assignment target in the current PEP.

I would much rather never have to read awful constructs like that than get
the minor convenience of:

    if (val := some_expensive_func()) > 0:
        x = call_something(val)

On Fri, Apr 20, 2018, 3:39 PM Chris Angelico <rosuav at gmail.com> wrote:

> On Sat, Apr 21, 2018 at 2:17 AM, Christoph Groth
> <christoph at grothesque.org> wrote:
> > Chris Barker - NOAA Federal wrote:
> >
> >> > Personally, I even slightly prefer
> >> >
> >> > a := 3
> >> >
> >> > to the commonplace
> >> >
> >> > a = 3
> >> > because it visually expresses the asymmetry of the operation.
> >>
> >> Careful here! That’s a fine argument for using := in a new language,
> >> but people using := when they don’t need an expression because they
> >> like the symbol better is a reason NOT to do this.
> >
> > Perhaps you are right and it is indeed unrealistic to expect people to
> > (eventually) shift to using := for simple assignments after 28 years of
> > Python...
>
> It's not just 28 years of Python. It's also that other languages use
> "=" for assignment. While this is by no means a clinching argument, it
> does have some weight; imagine if Python used "=" for comparison and
> ":=" for assignment - anyone who works simultaneously with multiple
> languages is going to constantly type the wrong operator. (I get this
> often enough with comment characters, but my editor will usually tell
> me straight away if I type "// blah" in Python, whereas it won't
> always tell me that I used "x = 1" when I wanted one of the other
> forms.)
>
> > One way or the other, I'd like to underline a point that I made
> > yesterday: I believe that it's important for sanity that taking any
> > existing assignment statement and replacing all occurrences of "=" by
> > ":=" does not have any effect on the program.
> >
> > PEP 572 currently proposes to make ":=" a binary operator that is
> > evaluated from right to left.
>
> This is one of the points that I was halfway through working on when I
> finally gave up on working on a reference implementation for a
> likely-doomed PEP. It might be possible to make := take an entire
> sequence of assignables and then set them left to right; however, this
> would be a lot more complicated, and I'm not even sure I want that
> behaviour. I don't want to encourage people to replace all "=" with
> ":=" just for the sake of it. The consistency is good if it can be
> achieved, but you shouldn't actually DO that sort of thing normally.
>
> Consider: one of the important reasons to define the assignment order
> is so you can reference a subscript and also use it. For instance:
>
> idx, items[idx] = new_idx, new_val
>
> But you don't need that with :=, because you can:
>
> items[idx := new_idx] = new_val
>
> (and you can use := for the second one if you wish). And actually,
> this one wouldn't even change, because it's using tuple unpacking, not
> the assignment order of chained assignments. I cannot think of any
> situation where you'd want to write this:
>
> idx = items[idx] = f()
>
> inside an expression, and thus need to write it as:
>
> g(items[idx] := idx := f())
>
> So I have no problem with a style guide saying "yeah just don't do
> that", and the PEP saying "if you do this, the semantics won't be
> absolutely identical to '='". Which it now does.
>
> Now, if someone else wants to work on the reference implementation,
> they're welcome to create this feature and then see whether they like
> it. But since I can't currently prove it's possible, I'm not going to
> specify it in the PEP.
>
> ChrisA
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180420/08a55cb5/attachment.html>