←back to thread

“I'm basically giving myself a permanent vacation from being BDFL”

(mail.python.org)
2024 points randlet | 3 comments | 12 Jul 18 15:22 UTC | HN request time: 0.754s | source
Show context
js2 ◴[12 Jul 18 16:15 UTC] No.17516019[source]▶
Background ("PEP 572 and decision-making in Python"):

https://lwn.net/Articles/757713/

replies(2): >>17516132 #>>17516693 #
bluecalm ◴[12 Jul 18 17:19 UTC] No.17516693[source]▶
Well, when he is dealing with arguments as silly as "but we will confuse = with ==) it's not a surprise he is tired and had enough. I just wish he had pushed through C style assignment before retiring. New syntax is ugly and introduces a new operator which basically does the same thing. When I've seen this PEP for the first time I thought he lost his touch after so many fantastic design decisions throughout the years. Now I realize he just had enough.

Thanks Guido for fantastic language. I wouldn't find love for programming if it wasn't for you.

replies(3): >>17516852 #>>17517193 #>>17518184 #
sevensor ◴[12 Jul 18 20:08 UTC] No.17518184[source]▶
My reaction was the opposite -- I didn't know about PEP572, read it immediately after this retirement announcement. My response was, "where has this feature been all these years?" I'm delighted by the addition -- it removes a lot of "loop and a half" ugliness without adding do loops, it simplifies list comprehensions, it lets you remove opportunities to make mistakes, and it doesn't let you put a single-equals assignment inside a conditional as a typo.
replies(1): >>17519038 #
sneakermoney ◴[12 Jul 18 22:11 UTC] No.17519038[source]▶
Same here, I often find myself writing a loop-and-a-half and will on occasion repeat expressions to get around extra lines (if I cared about performance, I wouldn't be writing it in Python).

I feel like a lot of the resistance is from people who think this is somehow bad style, because it's associated with a source of bugs in other languages. The same kind of people will argue endlessly against having 'goto' in a language, even when it can clearly make for cleaner code (eat it, Dijkstra!) in some cases.

replies(2): >>17520460 #>>17522652 #
bogomipz ◴[13 Jul 18 04:08 UTC] No.17520460[source]▶
Can you explain what a "loop-and-a-half" is in Python?
replies(1): >>17520537 #
1. blake_himself ◴[13 Jul 18 04:37 UTC] No.17520537[source]▶

    x = stuff
    while x:
        x = stuff
replies(1): >>17521139 #
2. Delgan ◴[13 Jul 18 07:36 UTC] No.17521139[source]▶
On the contrary, loop-and-a-half is intended to avoid repeating stuff outside and inside of the loop body.

    while true:
        x = stuff
        if not x:
            break
replies(1): >>17533866 #
3. chucksmash ◴[15 Jul 18 04:57 UTC] No.17533866[source]▶
GPs example is perfectly valid as well - this is just a restatement of the same logic in a way that keeps the logic contained within the loop at the cost of using a conditional plus a break inside of an unconditional loop. See [0]:

  Another motivating code pattern is the "loop and a half".
 
  It was once common for processing a file by line, but that 
  has been solved by making file objects iterable; however 
  other non-iterable interfaces still suffer from patterns 
  like:
  
  line = f.readline()
  while line:
      ...  # process line
      line = f.readline()
  
  or like this:
  
  while True:
      line = f.readline()
      if not line:
          break
      ... # process line

  Either of those could be replaced with a much more clear
  and concise version using an assignment expression:

  while line := f.readline():
      ... # process line
[0]: https://lwn.net/Articles/757713/