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 reduc…
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.)
Python 3.8.0a1 is now available for testing
21–30 of 59 posts
Re: Python 3.8.0a1 is now available for testing
#22Notably 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 reduc…
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.
Re: Python 3.8.0a1 is now available for testing
#23Re: Python 3.8.0a1 is now available for testing
#24Notably 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 reduc…
Re: Python 3.8.0a1 is now available for testing
#25I 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 !
Re: Python 3.8.0a1 is now available for testing
#26I 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 !
Re: Python 3.8.0a1 is now available for testing
#27Notably 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 reduc…
Imo the former is more readable and more pythonic
Re: Python 3.8.0a1 is now available for testing
#28I 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 !
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...
Re: Python 3.8.0a1 is now available for testing
#29Notably 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 reduc…
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.
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.Re: Python 3.8.0a1 is now available for testing
#30Earlier quoted context omitted.
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.
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…