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

CLI tools hidden in the Python standard library

til.simonwillison.net

Post reply on HN
Print view View original

101–110 of 160 posts

Re: CLI tools hidden in the Python standard library

#101

Post by [deleted] »

yunohn wrote: post #100
cxr wrote: post #73

Earlier quoted context omitted.

I find the entire premise of the post to be pretty baffling. > Seth pointed out this is useful if you are on Windows and don't have the gzip utility installed. Okay, so instead of installing gzip (or just using the decompressors that aren't the official gzip utility but that do support the format and already ship with Windows by default[1]), you install Python...? Even if the premise weren't muddy from the start, the…

You can definitely be in situations where you have python but not gzip.

[deleted]

Re: CLI tools hidden in the Python standard library

#102

Post by andreareina »

maleldil wrote: post #57
andreareina wrote: post #16

Earlier quoted context omitted.

I've taken to adding a --pdb option to my scripts.

What does it do? Just `import pdb; pdb.set_trace()`? Or `breakpoint()` after 3.7 (better because the user can override pdb with ipdb or other with `PYTHONBREAKPOINT`)?

Either breakpoint() or setting sys.excepthook to call the postmortem debugger.

Re: CLI tools hidden in the Python standard library

#103

Post by knodi123 »

dfc wrote: post #68

I am not someone who complains about "stop piping cats" but using '-e' with grep is a lot quicker and easier to read. This: grep -v 'test/' | grep -v 'tests/' | grep -v idlelib | grep -v turtledemo Becomes: grep -ve 'test/' -e 'tests/' -e idlelib -e turtledemo

not this? grep -ve 'test/|tests/|idlelib|turtledemo'

Re: CLI tools hidden in the Python standard library

#104

Post by agumonkey »

polyrand wrote: post #13

Python 3.12 will include a SQLite CLI/REPL in the standard library too[0][1]. This is useful because most operating systems have sqlite3 and python3, but are missing the SQLite CLI. [0]: https://github.com/python/cpython/blob/3fb7c608e5764559a718c... [1]: https://docs.python.org/3.12/library/sqlite3.html#command-li...

slightly related, emacs also includes an sqlite client / view now.. I find it funny to see everybody chasing the same need, and unsurprising since.. it's always good to have sqlite close to you.

Re: CLI tools hidden in the Python standard library

#105

Post by Karellen »

randlet wrote: post #69
bradrn wrote: post #48

Earlier quoted context omitted.

Wait, how does that work? As far as I can see from the documentation, it can only serve on localhost, which to my understanding is only accessible from the single device it was launched on.

If you serve on localhost you can usually access from other devices by using the "servers" ip address. So if your desktop where you're running the server has ip 192.168.1.10 then you can go to http://192.168.1.10 in the browser of another device on the same network.

But `localhost` is also an alias specifically for the loopback address (typically `127.0.0.1`), so "serve on localhost" can reasonably be interpreted as "serve on 127.0.0.1" which will only be available to other programs on that host, and not to others devices on the local network.

Re: CLI tools hidden in the Python standard library

#106

Post by sam2426679 »

BoppreH wrote: post #22

Speaking of hidden Python tools, I'm a big fan of re.Scanner[0]. It's a regex-based tokenizer[1] in the `re` module, that for reasons is completely missing from any official documentation. You give it a pattern for each token type, and a function to be called on each match, and you get back a list of processed tokens. Importantly, it processes the list in one pass and ensures the matches are contiguous, where a naive…

I believe this is used internally by json.loads, which is not very surprising in hindsight.

Re: CLI tools hidden in the Python standard library

#107

Post by maleldil »

RGBCube wrote: post #90
maleldil wrote: post #59

Earlier quoted context omitted.

It's weird that they're adding code to the stdlib without type annotations.

Lots of code in the stdlib does not have type annotations. Though I think most popular modules in the std either are annotated or have stubs somewhere.

I know, but I expected that to be restricted only to older modules. I don't expect them to annotate all existing modules.

I don't see why they would introduce _new_ code without annotating it, when that's clearly the trend for 3rd party libraries. From a quick look, it doesn't seem like it would be difficult to type either.

Re: CLI tools hidden in the Python standard library

#108

Post by telotortium »

maleldil wrote: post #107
RGBCube wrote: post #90

Earlier quoted context omitted.

Lots of code in the stdlib does not have type annotations. Though I think most popular modules in the std either are annotated or have stubs somewhere.

I know, but I expected that to be restricted only to older modules. I don't expect them to annotate all existing modules. I don't see why they would introduce _new_ code without annotating it, when that's clearly the trend for 3rd party libraries. From a quick look, it doesn't seem like it would be difficult to type either.

Maybe submit a patch?

Re: CLI tools hidden in the Python standard library

#109

Post by simonw »

dfc wrote: post #68

I am not someone who complains about "stop piping cats" but using '-e' with grep is a lot quicker and easier to read. This: grep -v 'test/' | grep -v 'tests/' | grep -v idlelib | grep -v turtledemo Becomes: grep -ve 'test/' -e 'tests/' -e idlelib -e turtledemo

Thanks, that's a useful tip.

Re: CLI tools hidden in the Python standard library

#110

Post by RGBCube »

maleldil wrote: post #107
RGBCube wrote: post #90

Earlier quoted context omitted.

Lots of code in the stdlib does not have type annotations. Though I think most popular modules in the std either are annotated or have stubs somewhere.

I know, but I expected that to be restricted only to older modules. I don't expect them to annotate all existing modules. I don't see why they would introduce _new_ code without annotating it, when that's clearly the trend for 3rd party libraries. From a quick look, it doesn't seem like it would be difficult to type either.

Isn't the change for the CLI? That's not accessible from scripts, so that may be why.

Though, I agree that typing everything is good. Especially when combined with a good typechecker like pyright.

Post reply on HN