Live data from Hacker News

Show HN: Making Python one-liner-fit with the new pwk (Python With Kurly braces)

github.com

21–30 of 78 posts

Re: Show HN: Making Python one-liner-fit with the new pwk (Python With Kurly braces)

#21

Can someone help me understand the rationale behind semantic whitespace as a replacement for explicit delimiters? Is it purely aesthetic?

Suppose you didn't have syntax highlighting. Would the braces be more distracting then?

Re: Show HN: Making Python one-liner-fit with the new pwk (Python With Kurly braces)

#22

Can someone help me understand the rationale behind semantic whitespace as a replacement for explicit delimiters? Is it purely aesthetic?

It forces consistent formatting within a file. But I think it was more relevant years ago. These days I see a lot of people using code formatters.

I still think one of Go’s best contributions was formatting with ‘go fmt’. It’s refreshing to see so many language communities just embrace a format on save standard and keep it moving.

Reading Python has always been a bit of a headache for me, but that probably has as much to do with the lack of type annotations as it does the lack of braces.

Re: Show HN: Making Python one-liner-fit with the new pwk (Python With Kurly braces)

#23
post #21

Can someone help me understand the rationale behind semantic whitespace as a replacement for explicit delimiters? Is it purely aesthetic?

Suppose you didn't have syntax highlighting. Would the braces be more distracting then?

> Suppose you didn't have syntax highlighting.

That might be a bit TOO contrived, at least for me. I could see this coming up for someone working with jurassic hardware not under their control though.

Anyway, to play along. I think curly braces help tell what is happening in long source files with deep nesting. But also you could just render whitespace characters as something visible to count them to judge indentation at a glance to get your bearings. Of course the real answer here is don’t write long source files with deep nesting, but unfortunately other people are allowed to write code :p

Re: Show HN: Making Python one-liner-fit with the new pwk (Python With Kurly braces)

#24
post #11

> Just download and chmod it No source? No thanks. Edit: Discard this comment! I thought pwk in the repo was an executable because it did not have a ".py" ending and did not care to check. Sorry!

"pwk" is both code and "executable" -- you can open it with any text editor. I didn't want to name it "pwk.py" to save on typing on the command line. --m

You don't need to sign your messages on HN (not really obvious since it's not written anywhere but it's one of those HN things)

Re: Show HN: Making Python one-liner-fit with the new pwk (Python With Kurly braces)

#25
post #21

Can someone help me understand the rationale behind semantic whitespace as a replacement for explicit delimiters? Is it purely aesthetic?

Suppose you didn't have syntax highlighting. Would the braces be more distracting then?

No, I think braces are even more useful when you don't have syntax highlighting.

Re: Show HN: Making Python one-liner-fit with the new pwk (Python With Kurly braces)

#26
post #21

Can someone help me understand the rationale behind semantic whitespace as a replacement for explicit delimiters? Is it purely aesthetic?

Suppose you didn't have syntax highlighting. Would the braces be more distracting then?

No they'd be even more useful.

I say that from experience: when I was first learning to program I found C much easier than python for this exact reason, and I was not using syntax highlighting.

That might be because I was much more prone to nesting back then. These days I get annoyed when I have two levels of indentation inside a function and treat three as a reminder to refactor. But when I started programming I'd build pyramids 8-10 levels deep and argued with people who tried to help simplify it.

Re: Show HN: Making Python one-liner-fit with the new pwk (Python With Kurly braces)

#28

Can someone help me understand the rationale behind semantic whitespace as a replacement for explicit delimiters? Is it purely aesthetic?

It forces consistent formatting within a file. But I think it was more relevant years ago. These days I see a lot of people using code formatters.

The flip side is, if you’re indenting you’re code anyway, as you probably should, then you might as well combine the style and meaning.

It works in practice, same difference to me tbh.

Re: Show HN: Making Python one-liner-fit with the new pwk (Python With Kurly braces)

#29
post #11

> Just download and chmod it No source? No thanks. Edit: Discard this comment! I thought pwk in the repo was an executable because it did not have a ".py" ending and did not care to check. Sorry!

"pwk" is both code and "executable" -- you can open it with any text editor. I didn't want to name it "pwk.py" to save on typing on the command line. --m

Wow, I feel _really_ dumb now - I just saw the filename without ".py" and assumed it was an executable

Sorry, I take it back!

Re: Show HN: Making Python one-liner-fit with the new pwk (Python With Kurly braces)

#30
I tried a few (not all) of the examples with plain old Python (granted, these are multi-liners, not one-liners, but I think they're easier to read). I'm not sure I see the advantange of curly braces.

  # --- Example 1
  
  # pwk
  pwk 'if "braces"=="bad": { print("Be gone!"); exit(99) } else: { print("Howdy!") }'
  
  # vs
  
  # python
  python -c 'if "braces"=="bad": print("Be gone!"); exit(99)
  else: print("Howdy!")'
  
  
  # --- Example 2
  
  pwk 'def s2i(s): { return int(s) } print(s2i("41")+1)'
  
  python -c 'def s2i(s): return int(s)
  print(s2i("41")+1)'
  
  
  # --- Example 3
  
  ls / | pwk 'for s in sys.stdin: try: { print(os.listdir("/"+s.strip())) } except: pass'
  
  ls / | python -c 'import sys, os
  for s in sys.stdin:
   try: print(os.listdir("/"+s.strip()))
   except: pass'
Post reply on HN