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.
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.
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.
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).
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.
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.
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 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.
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.
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.
The key changes seem to be [PEP-572], a bunch of small backward-compatible syntax changes, a bunch of AST (internal) changes, and bugfixes (of course).
# You can now write
if (match := pattern.search(data)) is not None:
# Do something with match
# or even
[y for x in data if (y := f(x)) is not None]
This is what I personally very much anticipated.
Also nice:
# This is now supported.
x: Tuple[int, int] = 1, 2 # No parens.
yield 1, 2, 3, *rest # No parens again.
There were notable performance improvments with several positional argument only functions made 1.3-1.7x faster in stdlib https://bugs.python.org/issue35582.
I am a proponent of LTS for Python 2.7x and existing libraries. This walrus operator is a fine new feature, for those that want it in Python 3.8x and beyond. Sorry, not sorry !
Are assignment expressions the only linguistic change?
For years,I've been holding my breath in Python for sum types, totality checking, and an enforced, complete type system -- one where you can say "this should be a list of lists of integers" and it won't let you put any other kind of thing there.
(Yes, there are external typing solutions like PyPy, but last I checked they did not offer complete type systems (you could specify that something is a list, but not that it's a list of ints), nor did they permit totality checking (so if type X is a sum type with two constructors X1 and X2, and f is a function that takes an X as input, and you forgot to define what happens if f is given an X2, it would not know to complain that you hadn't covered all possibilities).
What about functions, and functions of functions, etc? Can I specify that the argument to function f should be some other function g which should receive a list of ints and return a dict of functions with keys that are ints and values that are functions from int to int?
I expected a complaint after the second definition: I specified that g takes and returns a string, and then defined it to take and return an int. Not only did Python not catch the error at compile time (defining g), it didn't even catch it at runtime (calling g).
For some strange reasons Python developers decide to provide the syntax of type annotations but leave the actual checking to third party implementations.
Type annotations are just that: annotations. They currently have no meaning to the CPython interpreter and are purely consumed by external tooling (IDEs, there's a static typechecker called mypy, ...) or code that chooses to use them (e.g. there's web frameworks that convert and validate parameter types according to the signature of the handler function)
I use Haskell outside of work, and absolutely love it. (And in its case, too, I'm holding my breath for dependent types, which I believe are expected around summer of 2020.)
58 comments
[ 0.22 ms ] story [ 125 ms ] threadI personally think it's quite a nifty feature. I often end up writing something along the lines of:
Now that can be expressed as: It definitely has the potential to be abused and reduce readability, but applied well I think it can increase readability.[1] https://www.python.org/dev/peps/pep-0572/#relative-precedenc... [2] https://mail.python.org/pipermail/python-committers/2018-Jul...
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...
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).
Direct link: https://speakerd.s3.amazonaws.com/presentations/025e2c4bf551... (s/preview_// for a larger version)
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.
I... don't believe you. "Will not", "refuse to"? Sure. But "cannot", no.
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.
(In fact he's just been elected to the five-member council that has taken over that role.)
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.
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 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.
Hogwash. You choose to not.
`if foo == true:`
as
`if foo = true:`
which results in horrible subtle bugs
Also nice:
[PEP-572]: https://www.python.org/dev/peps/pep-0572/namedtuple attr access is also now 1.7x faster https://github.com/python/cpython/pull/10495
Other performance improvments : https://github.com/python/cpython/pulls?q=is%3Apr+sort%3Aupd...
I hope that 2019 is the year of PyPy adoption, as folks get ready to leave CPython.
[0] https://morepypy.blogspot.com/2016/08/pypy-gets-funding-from...
For years,I've been holding my breath in Python for sum types, totality checking, and an enforced, complete type system -- one where you can say "this should be a list of lists of integers" and it won't let you put any other kind of thing there.
(Yes, there are external typing solutions like PyPy, but last I checked they did not offer complete type systems (you could specify that something is a list, but not that it's a list of ints), nor did they permit totality checking (so if type X is a sum type with two constructors X1 and X2, and f is a function that takes an X as input, and you forgot to define what happens if f is given an X2, it would not know to complain that you hadn't covered all possibilities).
Python type annotations do support such use case: List[int].
What about functions, and functions of functions, etc? Can I specify that the argument to function f should be some other function g which should receive a list of ints and return a dict of functions with keys that are ints and values that are functions from int to int?
You are looking at the wrong language.
That said, the array module has been around for ages, for performance reasons.