7 ms·
Notably new is the assignment expressions [1]. This was quite controversial and the battle around it caused Guido to step down as BDFL [2]. I personally think
by luhn 8y ago
Notably new is the assignment expressions [1]. This was quite controversial and the battle around it caused Guido to step down as BDFL [2].
I personally think it's quite a nifty feature. I often end up writing something along the lines of:
result = do_something()
if result:
do_more(result)
Now that can be expressed as:
if result := do_something():
do_more(result)
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-precedence-of https://www.python.org/dev/peps/pep-0572/#relative-precedenc...
[2] https://mail.python.org/pipermail/python-committers/2018-July/005664.html https://mail.python.org/pipermail/python-committers/2018-Jul...
- yyyymmddhhmmss 8y agoI 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.
- gjm11 8y agoWhatever 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).
- JeremyBanks 8y agoYou have causality backwards. The vitriolic backlash to this change is part of why Guido stepped back from Python...
- mjw1007 8y agoNote 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.)
- JeremyBanks 8y agoThanks, reworded.
- muhbags 8y agoIt 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.
- gonational 8y agoI 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?slide=30 https://speakerdeck.com/di_codes/pep-572-the-walrus-operator...
- ssutch3 8y agoYes, you can. How do you think your brain learned the original way?
- gonational 8y agoIntuition 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).
- a1369209993 8y ago> 1. https://speakerdeck.com/di_codes/pep-572-the-walrus-operator?slide=30 https://speakerdeck.com/di_codes/pep-572-the-walrus-operator... Direct link: https://speakerd.s3.amazonaws.com/presentations/025e2c4bf55143678645a1f3a712e7d2/preview_slide_30.jpg https://speakerd.s3.amazonaws.com/presentations/025e2c4bf551... (s/preview_// for a larger version)
- legostormtroopr 8y ago
- mixmastamyk 8y agoIt 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.
- deleted 8y ago[deleted]
- IgorPartola 8y agoif a := 1 or b := 0: return a + b Good luck debugging why this doesn’t work.
- linux2647 8y agoThis 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.
- LawnboyMax 8y agoI believe or has higher precedence than := in this case thus the syntax error. Wrapping := in parentheses, like the other commenter suggested, resolves the issue.
- talltimtom 8y agoTo 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.
- IgorPartola 8y agoI 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.
- orf 8y agoFor 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]
- o10449366 8y agoAgreed. List comprehensions are where I see them being the most useful and where, in the past, I wished the functionality had existed.
- amyjess 8y agoI 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.
- mixmastamyk 8y agoIt's explicit with the new operator. The latter is true however.
- klodolph 8y agoI 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.
- legostormtroopr 8y agooutputs = [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.
- michaelcampbell 8y ago> I literally cannot read C code that does this, Hogwash. You choose to not.
- petercooper 8y agoQuick 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.)
- richardwhiuk 8y agobecause it's too easy to typo: `if foo == true:` as `if foo = true:` which results in horrible subtle bugs
- Zanni 8y agoTo 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.
- gigatexal 8y agoImo the former is more readable and more pythonic
- klodolph 8y agoI 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.