Hacker News Reader

Comment by blackhaz | Hacker News Reader

It's interesting to see the walrus operator in there. I wonder, is this another example of unnecessary features being added just to claim a bigger change list, or someone really needs this operator? Why would anyone prefer a walrus instead of adding just one more line to their code, which also helps with readability?

View on HN

This has been subject to endless discussions already and it's even a factor in Guido's decision to quit his role of BDFL.

You can find a detailed rationale in the relevant PEP: https://www.python.org/dev/peps/pep-0572/#rationale

Coming from Mathematica to Python, the lack of a assignment expressions yet inclusion of list comprehensions felt like a severe crippling of the language feature. Sure you “can still do the same through other means”, just like if, for and while are all unnecessary syntactic sugar in every language. But the thing is that list comprehensions provide a nice obvious concise way to frame your solution, but if you use it without assignment expressions you often end up repeating computations unnecessarily.

A while ago, I was also sceptical about the walrus operator, although I use assignments in expressions all the time in C++. But when I was perusing a library written Python the other day, I found five spots in which the walrus operator would make sense - eliminating one line of source code without readability suffering from it.

Is saving 5 lines of code really worth breaking Python's "one way to do it" design principle?

Python's principle is not an has never been "one way to do it". Python's principle is:

> There should be one — and preferably only one — obvious way to do it.

Which is a very, very different assertion. And there remains one — and exactly only one — obvious way to do an assignment, because the walrus operator is literally invalid syntax as a statement:

    >>> [a:=1]
    [1]
    >>> a:=1
      File "<stdin>", line 1
        a:=1
         ^
    SyntaxError: invalid syntax

That principle was bullshit anyway. There have always been multiple ways to do things, the one way was just whatever the elder Pythonista deemed to be pythonic that day.

Not true. The language optimizes for the way it is intended to be used, and changes remain sensitive to those optimizations.

"Pythonic" means intended usage, and "unPythonic" is shorthand for "you found another way to do it that kinda does what you want but (is ten times as slow/takes up ten times as much memory/doesn't work for edge-cases/has more unintentional side-effects) because it wasn't the intended usage, which is fine for your own personal projects, but please don't bring that into my code base, and pretty please don't teach other people to do it that way..."

In my work we have code in many places along the lines of:

    data = expensive_function(blah, blah_blah)
    if data:
        # many lines of processing
        data = expensive_function(blah, blah_bah)

And seen a lot of times where newcomers forget the assingment at the end that makes everything move. So yeah, the walrus version would be a lot simpler:

    while data := expensive_function(blah, blah_blah):
        # process data

This is just one of the "edge cases" where the walrus makes sense.

Yes. That principle was quite silly to begin with.

Reply on news.ycombinator.com