PEP 572: Python assignment expressions has been accepted

What is it? The link points to a discussion more deep than I’m willing to read.

Here is the PEP-572

https://www.python.org/dev/peps/pep-0572/

It's a controversial PEP https://www.python.org/dev/peps/pep-0572/ which allows you to write Python like this:

    def foo():
        if n := randint(0, 3):
            return n ** 2
        return 1337


    [(x, y, x/y) for x in input_data if (y := f(x)) > 0]

Ick.

You're allowed to do assignments inside of expressions

E.g.

    if(x:=f() is not None):
        print(x)

You can read more about it here: https://www.python.org/dev/peps/pep-0572/

High-level overview: it's an assignment operator that returns its value, similar to C's assignment operator.

The choice of := is to avoid accidentally using assignment where comparison is expected.

I've come around to it purely based on the application in list comprehensions.

Basically it's about adding := as an "assignment expression operator", that does assignment and returns the value as an expression. That is, take this regex example:

    match1 = re1.match(text)

    if match1 is not None:
        do_stuff()
    else:
        match2 = re2.match(text)

        if match2 is not None:
            do_other_stuff()

Which is a bit clunky. you only want to evaluate match2 in case match1 fails, but that means a new level of nesting. Instead, with this proposal, you could do this:

    if (match1 := re1.match(text)) is not None:
        do_stuff();
    elif (match2 := re2.match(text)) is not None:
        do_other_stuff()

Evaluate and assign in the if-statement itself. This is not dissimilar to the equals operator in C. In C, you would frequently find loops like `while ((c = read()) != EOF) { ... }`. This would presumably allow a similar pattern in python as well.

More information can be found in PEP-572: https://www.python.org/dev/peps/pep-0572/

It also seems include a special case for if/while that lets you do:

    def foo():
        if randint(0, 3) as n:
            return n ** 2
        return 1337

which looks a bit better to me.

The proposal: https://www.python.org/dev/peps/pep-0572/

Short version.

(x =: y) is an expression that:

1. assigns the value y to the variable x

2. has the value y.

So `print((x := 1) + 1)` prints '2', and sets x=1.

A ton of languages [eg: c, js] have '=' work this way. And a ton of style guides for those languages tell you to avoid using it like that, because it's confusing. So this is a bit controversial.

I'm immediately skeptical after seeing this example because I'm not sure if the first line parses as:

  if (x := f()) is not None:

or as:

  if x := (f() is not None):

Can somebody comment on why is this PEP controversial?

It makes list expressions and some other things more powerful, but some feel the potential to create difficult-to-understand constructs with it is too high and the current ways of writing such code are clear enough.

Would've making regular assignment an expression broken too much existing code?

For many people (including me) who learned Python the way that, in languages like C, the `if x=2` assignment combined with condition is an anti-pattern and prone to errors.

This PEP solves very little problem, saves a few characters of code, but adds complexity to readability.

Hehe. More chances for C-style bugs like:

if (a = b) /* Oooops, meant a == b! */

I think that's a rejected alternative proposal, not part of this PEP.

I feel the colon is unnecessary, especially considering how C deals with this. A plain '=' inside a conditional is already invalid syntax in Python.

:= overrules everything except a comma, so it's the latter. Still, I agree it's potentially confusing.

No, it's necessary.

And it's a very well-known source of bugs in C, since it's to close to "==". I don't think new languages adopting that is a good idea.

Difference is bigger, C is `if (a = b)` vs `if (a == b)`. Python is `if (a := b)` vs `if a == b`

Except it's more likely you're accidentally inserting a character twice than inserting another extra character (':')

How so? Syntactically, or from a pragmatic point of view?

Presumably that's why they've gone with the far more sensible ":=" syntax.

The use of "=" for assignment has long been a pet peeve of mine. It was a mistake when C did it, and it's been a mistake for so many subsequent languages to copy it.

"=" shouldn't be an operator at all, it makes a lot more sense to use ":=" and "==".

Pascal's use of ":=" for assignment and "=" for equality, strikes me as almost as clear.

Still, at least C makes consistent use of '=' for assignment, unlike that god-forsaken trainwreck of a language, VB.Net, which uses it for both assignment and for equality depending on context.

Sure. But if fidelity to C style was not a concern then I don't see why the '==' syntax was adopted in the first place.

Probably not, since expressions can already be statements. But that would allow dangerous code like "if a = 3", which I don't think the Python devs would want to allow.

This immediately looks useful for things like:

    if foo := bar[baz]:
        bar[baz] += 1
        return foo
    else:
        bar[baz] = 1
        return 0

Where foo is a dict keeping track of multiple things, and a non-existing key (baz) is never an error but rather the start of a new count. Faster and more readable than

    if baz in list(bar.keys()):
    ....

Similar to Swift’s ‘if let’, it seems.

For stuff like that I'd just use `defaultdict`. That if/else tree then reduces to 2 lines total.

That’s a good tip, thanks!

This is horrible. It looks like ":=" is a comparison operator. The last line is dangerously close to Erlang list comprehensions:

[ {X, Y, X/Y} || X <- Some_Function (), Y <- Some_Other_Function () ]

And people bitch about Erlang syntax.

Edit: "/" is the division operator

As pointed, you can use either a default dict or just simply, and [more pythonic](https://blogs.msdn.microsoft.com/pythonengineering/2016/06/2...):

    try:
      bar[baz] += 1
    except KeyError:
      bar[baz] = 1

Also you can check if a key is in a dict simply by doing "if baz in bar" no need for "list(bar.keys())", which will be slow (temp object + linear scan) vs O(1) hashmap lookup.

Reminds me of the kind of hacks you would find in an old-school K&R book.

I don't think the controversy here is with the feature itself, more with the implementation. Many, me included, would have preferred to seen a different implementation of solutions to the same problems.

Code starts becoming a lot harder to reason about when more than one state is mutated on the same line. The good design of Python makes this harder than in say C and I think this is a step in the wrong direction in that regard.

The two real things this solves are checking for truthyness in an if and reusing values in a filterting comprehension. Instead of the syntax we have now that can be used anywhere, adds a whole new concept and feels kind of out-of-place, I would have much preferred a solution that can only be used in vetted places, doesn't add a new thing people need to learn and follows the style of the language

For example, my preferred solution for `if` would have been:

    if thing() as t:
        print(t)

Usage of `as` is already established by the `with` block

    [value for x in y
     if value
     where value = x * 2]

The order is unfortunately a bit weird here, but there is no need to add the whole concept of a different type of assignment and this syntax will feel instantly recognizable to people familiar mathematical notation, which is where the existing list comprehension syntax comes from and so has been established as well.

Don't wait for 3.8, and don't bother with defaultdict.

collections.Counter is what you want for the counting case.

dict.get() + dict.setdefault() for the general case.

defaultdict is only useful if the factory is expensive to call.

It's a voluntary design choice since the beginning of Python to avoid the very common mistake of doing:

    while continue = "yes":

instead of:

    while continue == "yes":

Those mistakes introduce bugs that are hard to spot because they don't cause an immediate error, linters can hardly help with them and even a senior can make them while being tired.

I wanted "as" too. But the accepted operator has the benefit of integrating perfectly with type hints.

That's why parenthesis are mandatory.

The place I see using it is in (quoting Python's "python.exe-gdb.py"):

        m = re.match(r'\s*(\d+)\s*', args)
        if m:
            start = int(m.group(0))
            end = start + 10

        m = re.match(r'\s*(\d+)\s*,\s*(\d+)\s*', args)
        if m:
            start, end = map(int, m.groups())

With the new syntax this becomes:

        if m := re.match(r'\s*(\d+)\s*', args):
            start = int(m.group(0))
            end = start + 10

        if m := re.match(r'\s*(\d+)\s*,\s*(\d+)\s*', args)
            start, end = map(int, m.groups())

This pattern occurs just often enough to be a nuisance. For another example drawn from the standard library, here's modified code from "platform.py"

    # Parse the first line
    if (m := _lsb_release_version.match(firstline)) is not None:
        # LSB format: "distro release x.x (codename)"
        return tuple(m.groups())

    # Pre-LSB format: "distro x.x (codename)"
    if (m := _release_version.match(firstline)) is not None:
        return tuple(m.groups())

    # Unknown format... take the first two words
    if l := firstline.strip().split():
        version = l[0]
        if len(l) > 1:
            id = l[1]

The error-catching method seemed too drastic to me before, but the article explains the LBYL vs. EAFP arugument quite well. Thanks!

I should find a way to get more code reviews, I really enjoy learning these small nuggets of info.

It's also time saving since the hash lookup needs to be done at most 1, as well. GP has two lookups in the hash list.

Alternatively

`bar[baz] = bar.get(baz, 0) + 1`

One line and no error checking.

But the OP was probably just illustrating a basic example where you might have some more intense logic

== is an incredibly common syntax for equality and stand-alone not a problem. only if you introduce = to expressions too it becomes a risk. (well, you could theoretically accidentally write == for a normal assignment, but that kind of error is caught more easily)

It's not a problem in C anymore as modern compilers warn about that so you had to put additional parenthesis to make it clearer.

I like C way of assignment being an expression. I think having separate statement and then assignment expresdion is a mess. It's still useful though as Python was missing where keyword like feature from Haskell which is necessary to avoid duplicating computation in list comprehension.

I don't know about linters but GCC warns me about that every time I make that typo. They could just require parenthesis when assignment value is used as boolean.

Yeah but there is already solution for that in C: put parenthesis around assignment when using its value as bool. The compilers warn if you don't so making this error in C can only happen if you don't use warnings.

It' a problem with re module really.

re.match should return a match object no matter what, and .group() should return strings, empty string if non were matched.

I don't see how that would improve things. Could you sketch a solution based around your ideas?