PEP 572 assignment expressions

[vandys]

We should definitely plan on supporting assignment expressions, PEP 572.

The fight for it was so ugly that I see Guido's stepping back from BDFL! :(

[vandys]

I'm up for adding this, BTW. Is the style of the project that we wait for Python 3 to have it,
and then crib their code as much as possible? (NM, found their WIP patches. Dang, the
language lawyers have sure made Python complex!)

[vandys]

Ok, I've read the PEP and a bunch of Guido's comments. It's clear he wanted this to be much more
orthogonal, but compromised because of politics (some dictator, huh?).

The truth is := looks a LOT like +=, /=, and friends--augmented assignments. So I'm going to code
it to be another one of those, then make augmented assignments be usable as rvalues, so
you can do:
if ((a := myfunc()) < 2):
for exactly the same reason you can do:
if ((a += INCR) < LIM):
And with right association you get the expected result for:
a := b := 3
Though I can't see why you'd use it over traditional assignment. I must say, when you
say assignments are not rvals, and then you want:
a = b = 3
You have to then right special case code (which cPython does, assignments have an
actual list of lvals to receive the rval).

[naftaliharris]

Is the style of the project that we wait for Python 3 to have it,
and then crib their code as much as possible? (NM, found their WIP patches. Dang, the
language lawyers have sure made Python complex!)

Yup, that's right. Here's an example of how I did this for adding the nonlocal keyword: https://www.naftaliharris.com/blog/nonlocal/

[vandys]

Is Lib/compiler being ignored when adding Python 3 features? The docs appear to say it's
deprecated as of 2.6 (and gone from 3). I can certainly update it if you prefer.

[naftaliharris]

We generally try to backport changes there as well.

…

On Sat, Jul 14, 2018, 10:04 PM Andy Valencia ***@***.***> wrote: Is Lib/compiler being ignored when adding Python 3 features? The docs appear to say it's deprecated as of 2.6 (and gone from 3). I can certainly update it if you prefer. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#94 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABysKxzFQ8-ZzAsPJKLeL6-ZjlwB4VoRks5uGs1FgaJpZM4VNUKe> .

[vandys]

Ok, will test that tomorrow. vandys/tauthon branch pep572 is fairly complete code (he says
hopefully). I made := an augmented assignment, and it along with all other augmented assignments
are usable as expressions. So you can do "while l := foo.read(): ...", but also
"if (ob.count -= 1) > 0: ...", things like that. "a := b := 123" also work as expected,
not because I wrote extra special cases, but because hey, that's how a right associative
expression operator works. I'll flesh out tests, fix an edge case on slices, and also look
at that Python parser; I added the code, but haven't tested.

[vandys]

I'll tidy this up and resubmit.

[vandys]

Oops, meant to wave off the PR, not the issue. Doh.

This assertion failure points to a deeper issue, thus the PR withdrawal. Python has painted itself
a bit into a corner. A programmer could easily write:

a = 1
b = 2
c = a +=1, b += 1

And expect c == [2, 3] with a == 2 and b == 3.
But this fights you:

a = [1, 2]
a += 3, 4

Which in Python gives you a == [1, 2, 3, 4].

So precedence is distinct for augmented assignment (though their result can still be used
as a value) and the new assignment expression ":=". Which, to meet PEP572, needs
to give the result:

a = 1
c = (a := 2, 3)

with a == 2 and c == [2, 3].