Live data from Hacker News

CLI tools hidden in the Python standard library

til.simonwillison.net

131–140 of 160 posts

Re: CLI tools hidden in the Python standard library

#131
post #109
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.

Also since ripgrep is already installed "grep -v" can be replaced with "rg -v"

Re: CLI tools hidden in the Python standard library

#132
post #99
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

To be fair, the advantage of doing separate greps is working iteratively and drilling down on what you want.

You can iteratively add the -e flags just the same.

Re: CLI tools hidden in the Python standard library

#133
post #36

Nice! I use this on winboxes: zipfile Decompress a zip file: python -m zipfile -e archive.zip /path/to/extract/to Compress a directory into a zip file: python -m zipfile -c new_archive.zip /path/to/directory

is there an advantage to this over windows builtin zip feature? I don't know if it is usable from CLI.

Re: CLI tools hidden in the Python standard library

#134

Earlier quoted context omitted.

iirc this is one of the things earmarked for a hypothetical Python 4, making -P the default. It's also one of the many relatively well-known (security) issues in Python that don't get addressed for a surprising amount of time. Others in the same vein would be stuff like stderr being block-buffered when not using a TTY, no randomized hashes for the longest time, loading DLLs preferably from the working directory, std*…

-P?

https://docs.python.org/3/using/cmdline.html?highlight=q#cmd...

had to look myself. apparantly, it's like setting PYTHONSAFEPATH which prevents 'unsafe' paths from getting added to sys.path. new in 3.11

Re: CLI tools hidden in the Python standard library

#135
post #67

Earlier quoted context omitted.

I use miniserve (`cargo install miniserve`). You also have available `npx serve`.

Oh and the Rust brigade have arrived... Was only a matter of time.

How dare people mention tools written in Rust?

It may be a fantastic, well loved language that's exploding in popularity and the source of endless very high quality CLI tools... but. The absolute cheek!

We must only mention Python and Bash forevermore.

Re: CLI tools hidden in the Python standard library

#136
post #66
post #39

Earlier quoted context omitted.

Especially now that they are on a crusade against their own stdlib. They regret including most modules… it seems they regret making python altogether instead of sticking with C? :D

This is quite an oversimplification. Some modules have no active maintainers and take time from the small team that work on CPython. Some modules are deprecated and removed to make it possible to allocate time on other improvements, and they went back on some removals when users came forward showing that they were still needed. There is some discussion about the rationale at https://peps.python.org/pep-0594/#rational…

Did you read the latest news or not? They regret asyncio! (and many other core modules).

They won't remove them… but they regret having made them.

I think without, people would have just not used python.

Re: CLI tools hidden in the Python standard library

#137
post #86

Earlier quoted context omitted.

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.

Please don't derail discussions with zero-effort, low-substance nonsequitur oneliners like this.

Re: CLI tools hidden in the Python standard library

#138
post #2

Its notable, perhaps, that the if __name__ == "__main__": block allows you to do this for a _module_, i.e. a single *.py file. If you want to do this for a package, add a `__main__.py` You can also use either of these throughout your code so that you can have python -m foo python -m foo.bar python -m foo.bar.baz each doing different, but hopefully somewhat related, things.

It also uses the file as a module, not a script, which means suddenly relative imports works the root dir and the cwd are the same, and it is added to sys.path. This prevents a ton of import problems, albeit for the price of more verbose typing, especially since you don't have completion on dotted path. It is my favorite way of running my projects. Unfortunalty it means you can't use "-m pdb", and that's a big loss.

I've always been curious how that mechanism works exactly what is it about that invocation technique that satisfies the relative imports? I think it changes the pythonpath somehow right in a way related to the module being ran, something like appending the basedir where the module is saved to the PYTHONPATH?

Re: CLI tools hidden in the Python standard library

#139

Shame gzip has one but zlib does not, that would be a very useful addition: some software create raw zlib streams on disk (e.g. git) and there’s no standard decompressor, you need to either prepend a fake gzip header, go through openssl, qpdf‘s zlib-flate, or pigz -z.

You can combine -m and -c to use zlib

Re: CLI tools hidden in the Python standard library

#140
post #80
post #63

Earlier quoted context omitted.

> They regret including most modules… it seems they regret making python altogether instead of sticking with C? :D I also find it odd. Python would probably be a little known language without the huge batteries included by default. It's invaluable when you're working in a environment where you can't fully control what is installed, what is the case of most people at work. I believe this crusade endangers the language…

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/

I was referring to this: https://pyfound.blogspot.com/2023/05/the-python-language-sum...

Of course nobody even knew so the default response is to hit that bottom arrow :D

Post reply on HN