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.
CLI tools hidden in the Python standard library
131–140 of 160 posts
Re: CLI tools hidden in the Python standard library
#132I 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.
Re: CLI tools hidden in the Python standard library
#133Nice! 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
Re: CLI tools hidden in the Python standard library
#134Earlier 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?
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
#135Earlier 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.
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
#136Earlier 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…
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
#137Earlier 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.
Re: CLI tools hidden in the Python standard library
#138Its 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.
Re: CLI tools hidden in the Python standard library
#139Shame 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.
Re: CLI tools hidden in the Python standard library
#140Earlier 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/
Of course nobody even knew so the default response is to hit that bottom arrow :D