Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python 3.8.0a1 is now available for testing

pythoninsider.blogspot.com

Post reply on HN
Print view View original

11–20 of 59 posts

Re: Python 3.8.0a1 is now available for testing

#11

Post by IgorPartola »

luhn wrote: post #2

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…

    if a := 1 or b := 0:
        return a + b
Good luck debugging why this doesn’t work.

Re: Python 3.8.0a1 is now available for testing

#12

Post by orf »

luhn wrote: post #2

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…

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)
You could break this into two comprehensions, sure, but it's annoying. With this:

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

Re: Python 3.8.0a1 is now available for testing

#13

Post by amyjess »

luhn wrote: post #2

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…

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

#14

Post by ssutch3 »

gonational wrote: post #5
muhbags wrote: post #4

Earlier 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.

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...

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

Re: Python 3.8.0a1 is now available for testing

#15

Post by o10449366 »

orf wrote: post #12
luhn wrote: post #2

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…

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) You could break this into two comprehensions, sure, but it's annoying. With this: [result for x in values if (result := func(x))

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

Re: Python 3.8.0a1 is now available for testing

#16

Post by gjm11 »

yyyymmddhhmmss wrote: post #6
luhn wrote: post #2

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…

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).

Re: Python 3.8.0a1 is now available for testing

#17

Post by nine_k »

mikepurvis wrote: post #8
nine_k wrote: post #3

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 par…

That list comprehension is the most compelling case I've seen for this functionality; far more so than the basic assignment + if.

Yes, sometimes, writing a comprehension, I was dearly missing the `let` / `where`, as seen in e.g. Haskell, or lisps.

Re: Python 3.8.0a1 is now available for testing

#18

Post by petercooper »

luhn wrote: post #2

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.)

Re: Python 3.8.0a1 is now available for testing

#19

Post by richardwhiuk »

petercooper wrote: post #18
luhn wrote: post #2

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.)

because it's too easy to typo:

`if foo == true:`

as

`if foo = true:`

which results in horrible subtle bugs

Re: Python 3.8.0a1 is now available for testing

#20

Post by snazz »

muhbags wrote: post #4
luhn wrote: post #2

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…

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 less readable to someone who hasn’t studied the new operators yet.
Post reply on HN