Live data from Hacker News

CLI tools hidden in the Python standard library

til.simonwillison.net

111–120 of 160 posts

Re: CLI tools hidden in the Python standard library

#111
I answered a question on SO over a decade ago on this topic, back in the Python 2.7 era: https://stackoverflow.com/a/14545364/1204143

One of these days it would be nice to make an unofficial Python reference book which documents these tools, hidden features (like re.Scanner!), and other corners of the stdlib or language.

Re: CLI tools hidden in the Python standard library

#112
post #86
post #75

Earlier quoted context omitted.

Most people who read this blog already have python installed

The bafflement increases. The topic of this thread is the safety and security of running Python on (or merely next to) arbitrary content. Even ignoring that: is "most people" greater than, less than, or the same amount as "all"?

> The bafflement increases.

So does the pendantry.

Re: CLI tools hidden in the Python standard library

#113
post #25

> Pretty-print JSON: > echo '{"foo": "bar", "baz": [1, 2, 3]}' | python -m json.tool This is even more fun on MacOS if you combine it with the pbpaste/pbcopy utils: alias json_pretty="pbpaste | python -m json.tool | pbcopy" That command will pretty-print any JSON in your clipboard, and write it back to the clipboard, so you can paste it somewhere else formatted!

I have a similar mapping to use `json.tool` inside of vim buffers. Very useful tool that's gotten a ton of mileage from me over the last ~decade.

Re: CLI tools hidden in the Python standard library

#114
post #24

Why would you rely on any of these? They can be deprecated at a whim like distutils and many other things. That's why Python requires so many blog posts.

If by on a whim, you mean after removal after 6 years of being warned against (the first "maybe use setuptools instead" note was in Python 2.7.12 in 2016), deprecation was proposed in october 2020, agreed in january 2021, and removal will happen in Python 3.12, which... hasn't been released yet.

Re: CLI tools hidden in the Python standard library

#115
post #95
post #80

Earlier quoted context omitted.

You're reading a ridiculous mischaracterization of reality (~20 deprecated modules [1] out of the ~300 PSL modules [2] is "most"?). Of course you find it odd. [1] https://peps.python.org/pep-0594/ [2] https://docs.python.org/3/library/

It's the trend that is a bit worrying. It's definitely been floated more than once that the stdlib should be fundamentally gutted. It has not become a reality yet, but there are some loud voices advocating to just chuck most modules as a principle into pypi.

There are two strong reasons for that:

(1) Not letting little used modules that pose maintenance problems drive up the cost of maintaining Python, and

(2) Not forcing actively used, actively developed modules to be limited to the core language upgrade cadence (and not forcing users to upgrade the language to get upgrades to the modules.)

Ruby I think has a decent approach to this (particularly, one that deals with #2 better than just evicting things entirely from the standard distribution) with “Gemification” of the standard library, where most things that are moved out of the standard library aren’t moved out of the standard distribution, but into a set of gems distributed with the standard distribution but which can be upgraded independently.

Re: CLI tools hidden in the Python standard library

#116
post #96

Earlier quoted context omitted.

Doing that requires palcement of files right in the directory where the user is likely to run that module. Seems to be a quite rare vector for exploitation. Sure, on a multiuser system I might trick some other user into running such a command in /tmp and prepare that directory accordingly, but other vectors seem more esoteric.

There are thousands of tools (shellscripts, makefiles ...) which execute "python -m": https://www.gnod.com/search/?engines=af&nw=1&q=python%20-m Even in Google's own repos. Starting any of those (no matter where they are stored) in a hostile repo would let the code in the repo take over the machine.

If you run anything in a hostile repo, you already lost.

Re: CLI tools hidden in the Python standard library

#117
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…

This is one of the best ChatGPT use cases: creating regex complex patterns

I agree. I made a little code formatter for aligning variable assignments on adjacent lines and used chatgpt for a lot of help with the regex

Re: CLI tools hidden in the Python standard library

#118

Earlier quoted context omitted.

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?

The standard library has type hints in the "typeshed" github repo. Please do not submit PRs to cpython to add type hints (I made this error before too:))

Re: CLI tools hidden in the Python standard library

#119
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'

That would be -vE, or you have to escape the pipe symbols.
Post reply on HN