Show HN: Making Python one-liner-fit with the new pwk (Python With Kurly braces)
github.com
github.com
# --- 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'[1] https://twitter.com/AbhishekGhose/status/500564420733304833?...
[2] http://quipu-strands.blogspot.com/2014/08/knn-classifier-in-...
I don't know about most people, but interactively I use short flags and when writing Bash scripts I try hard to use long flags and will often break things up specifically for clarity.
>some_complex_tool | 'my one liner' | some_other_complex_tool > result.txt
Not putting the one-liner logic into a separate script avoids an additional lookup for someone learning what is going on, along with any deployment/path/.. dependencies to that separate script.
You can do this using contexlib. For example the following in pwk:
try: { print(os.listdir("/"+s.strip())) } except: pass
with contextlib.suppress(Exception): print(os.listdir("/"+s.strip()))
You could probably also make a context manager which takes a function/lambda to define how to handle exceptions etc.
I've ended up using Groovy for this level of scripting, and it works really well.
#!/usr/bin/env python
print("Hello, world!")
If you mean invocation as "execute a command that I'm passing", 'python -c' does exactly that.
Even as a complete shell it works including changing directories and using standard python to do file IO, though it won't execute any system executables and doesn't do piping like you'd like from a shell. It's not intended for that purpose so I can't really blame python for that.
I think that's what xonsh was made for? :)
I wasn't aware of this. I guess it might silence a few critics.
However I'd be much more interested to try "Javascript with semantic white space"
But you're absolutely right, it made my code really hard to reason about. I don't know why this is the case but it was always harder to read my own CS than raw JS. I found myself putting blocks into the CS2JS just to read inner workings.
While it made me less verbose and short-term faster, longer term it made me slower.
$ python -c 'from __future__ import braces'
File "<string>", line 1
SyntaxError: not a chance...
I just attempted to type out an example and found a reason not to do this... it's the same reason c needs parentheses around the conditional. On the balance, I prefer parentheses over the vestigial colon.
But I think it was more relevant years ago. These days I see a lot of people using code formatters.
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.
However, languages that have a line length limit are the blight of them. There isn't a python formatter that won't make everything mush. My if clause that is 81 chars wide doesn't need to be broken up. Similar, my strings don't need to be reflowed.
Go fmt ignores line length, and always produces a formatted file that is pretty as a result.
I don't like long lines, but reflowing logic is way to aggressive in these formatters.
It works in practice, same difference to me tbh.
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
Like the late 1980s, when Guido was creating Python?
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.
I hear the argument quite frequently that semantic whitespace makes it hard to move code around (or that it causes code to get messed up in various ways) and I keep wondering why that doesn't describe my own experience as a daily user of Python. Maybe a lot of it is that I tend to avoid more than a couple of levels of indentation like the plague, and therefore it's rare for there to be any confusion about where a particular line of code would "belong".
'{}' has the advantage that it expresses structure in a single line - copy a block of code from one place to another and your editor can throw it almost anywhere and the structure is preserved...
Modern day text editors all preserve indent wonderfully and can indent/outdent as a matter of course...but to some troll insisting on using ed or notepad or Microsoft Word I can see the difficulty.
I'd call it pragmatic.
I think it's Python's only real strength. The language is ugly, the interpreter is a genuinely deficient way of making software ("Why use a compiler when you can just write thousands of unit tests to check for syntax errors!?"), and the mechanisms for abstraction are fairly weak - even after all that, n00b Python code is fairly readable.
You can never have a "goto fail" kind of bug.
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!
Sorry, I take it back!