It is a nifty feature. However a lot of us wanted it to use the "as" keyword (like in SQL and Python) instead of more colons, which are multiplying.

Unfortunately "as …" had a few drawbacks in rare use cases (:= has only aesthetic drawbacks), but I think as was by far the most consistent, readable choice and supported ~90% of use cases.

As for the controversy, that's what happens when you reverse 25 year-old design decisions. Shouldn't be too surprising.

It is definitely useful, but it severely reduces readability in my opinion. Your example is also a great example for this. The first version in way more readable than the second version with the walrus operator.

I agree with you.

It's very exciting to remove these sorts of redundant lines, but I cannot train my brain to intuitively view that line as it will be interpreted.

There is one case where the benefit, IMHO, far outweighs the negatives, and that can be seen in slides 30-31 of Dustin Ingram's slideshow[1].

PEP 572... the day Python jumped the walrus.

1. https://speakerdeck.com/di_codes/pep-572-the-walrus-operator...

I can't take a programming talk seriously if it declares in giant font "Less lines are better" (slide 38).

Any C program can be written as a single line, with no linebreaks - that doesn't make it "better" by any metric.

Python is built around its readability, and slide 44:

> group = match.group(1) if (match := re.match(data)) else None

is anything but. 'match' is assigned after its first use, and it took me far to long to mentally parse what it was doing.

C is different than python though. Python already forces readability things like forcing indent and newline. In most scenarios making a python program in as few lines as possble will make the program more readible.

Yes, you can. How do you think your brain learned the original way?

Intuition is defined as being based on what one feels to be true even without conscious reasoning.

Something that is unnatural, such as an operator mixed with an expression is anything but natural, in the context of Python.

I can force myself to recognize the pattern; yes.

Also, the example I linked to in the slide show does feel somewhat intuitive (usage in a while loop).

> 1. https://speakerdeck.com/di_codes/pep-572-the-walrus-operator...

Direct link: https://speakerd.s3.amazonaws.com/presentations/025e2c4bf551... (s/preview_// for a larger version)

This feels very Perl-y in the example given, in that it requires that you know what yet another operator means to read code that uses it. Since Python is supposed to be “executable pseudocode” (roughly), this kind of new operator might increase the amount of learning that a beginner has to do to read others’ code. I hope that this decision does not pave the way for more like it, because it would make Python code much less readable to someone who hasn’t studied the new operators yet.

Yeah I feel like this is going to lead to another situation like with Python classes, where it's fine (and good!) to use them in libraries but generally not so good to use them in user code. The next time I update my own style guide it will probably say something like it's ok to use the walrus operator in service methods, but not in views, since views should be readable even to front end devs and PMs who don't know any Python or Django.

"readability" is such a crap excuse for or against things. Everything is unreadable until you learn to read it. Reading is simply a mapping of what you see, to internalized meaning.

Even if you accept that there is some continuum of "...ability" of these things, it's completely arbitrary and unique to everyone as to where the line between "this should be in" and "this should be out" lies.

For me the big thing is the case where you want to use a list comprehension with a somewhat expensive function:

   [func(x) for x in values if func(x) < 10]

You could break this into two comprehensions, sure, but it's annoying. With this:

   [result for x in values if (result := func(x)) < 10]

Agreed. List comprehensions are where I see them being the most useful and where, in the past, I wished the functionality had existed.

    if a := 1 or b := 0:
        return a + b

Good luck debugging why this doesn’t work.

This statement returns a syntax error. But I get what you mean. For

  if (a := 1) or (b := 1):
    print(locals())

since a is truthy, it gets bound and is in scope, whereas b is not, which makes sense to me.

To understand that you need to understand “if”, “or” and assignment expressions. You think this is hard to understand, and that’s fair, but the hard point here isn’t the assignment expression, it’s the short circuiting or-statement. You’d have the same issues with debugging “if f() or g():...”

So are you arguing that the language should not have short-circuit or-statements?

That just seems like you are sacrificing tons of usability only to slightly improve on the expectations of those who are just starting python, like the first 1-2weeks of trying to learn it.

I am arguing for short circuiting and against assignment expressions returning. You save one line per assignment while also making everything more confusing. Next thing you know we will be debating why a++ is a thing and how it that now returns so you can use it in if statements.

I believe or has higher precedence than := in this case thus the syntax error. Wrapping := in parentheses, like the other commenter suggested, resolves the issue.

Quick question.. why is a new operator needed? A lot of languages consider regular assignments to be expression as-is, so why couldn't `if result = do_something():` work? (Genuine question, I'm intrigued what the clash is as I rarely use Python.)

To reduce the chance of creating an assignment expression when you intended a simple comparison. Yes, there's already a different operator for equality, but it's easy to mistake = for ==. Forcing you to use := makes it a deliberate act, and makes your intention clear to the reader.

because it's too easy to typo:

`if foo == true:`

as

`if foo = true:`

which results in horrible subtle bugs

I find it always decreases readability.

I literally cannot read C code that does this, now I'm going to have to worry about encountering unreadable Python code.

Edit: Also, it violates both "explicit is better than implicit" and "there should be one and only one right way to do it". It's inherently Unpythonic.

I agree that it's a violation of the “one and only one” maxim, but that maxim is a bit hard to take as an absolute. I think the problem is that there are already a lot of ways to write things in Python, the biggest example that comes to mind is list comprehensions.

    outputs = [f(x) for x in inputs]

Versus:

    outputs = []
    for x in inputs:
        outputs.append(f(x))

The assignment expression lets you:

    outputs = [y for x in inputs
               if (y := f(x)) is not None]

I know that more complicated list comprehensions in Python are a bit of a sore point for some people, but I would say that they’re also inherently unpythonic, and I like them.

    outputs = [y for x in inputs
               if (y := f(x)) is not None]

I can't stand this new syntax, y is declared and assigned after the first instance of its use.

It's explicit with the new operator. The latter is true however.

> I literally cannot read C code that does this,

Hogwash. You choose to not.

Imo the former is more readable and more pythonic

I think “Pythonic” is up there as one of my least-favorite terms of all time. I think, 99% of the time, when people say “Pythonic” they should really just be quoting one of the lines from PEP 20.

I am already disappointed in post-Guido Python. Although the walrus operator makes enough sense to me, it doesn’t solve anything that I consider a problem so I can’t reason that it was worth going against so much pushback.

Whatever else the walrus operator is, it isn't "post-Guido Python". Guido was one of the authors of PEP 572, pushed for its acceptance, and was still BDFL when it was officially accepted into Python (by Guido).

You have causality backwards. The vitriolic backlash to this change is part of why Guido stepped back from Python...

Note Guido hasn't left Python. He just didn't want to be the sole final-decision-maker any more.

(In fact he's just been elected to the five-member council that has taken over that role.)

Thanks, reworded.