[dead]
Using Python for Scripting
91–100 of 112 posts
Re: Using Python for Scripting
#92So they suggest to write scripts in Python rather than shell because Python is stable, probably installed on the target machine, has a big standard library, and is more readable. Many people do so.
That's the bright side of Python. They should mention the dark side, or Why _not_ to use Python for scripting.
First of all, the promise of easy portability breaks as soon as the script has dependencies. Try to install some Python program on a server where you're not root and a minimal python3 is installed.
The stability isn't very good in my experience either. I've often seen programs not compatible with recent releases of Python, either explicitly in the README or implicitly at runtime. Unmaintained Python code breaks.
Unfortunately, there is no silver bullet. Posix shell or bash may be better for simple scripts; Perl or Python if you know you won't require dependencies or if you have a good control on where to install the script; languages that compile to static executables are not really "scripting", but may be a better choice for long(term usage. These past years, I tend to keep away from Python as much as I can.
Re: Using Python for Scripting
#93Why not use Perl?
Because it is write-only.
Re: Using Python for Scripting
#94How do you handle packages? I want scripts to a be a single file with a shebang, not a repo with a requirements.txt that I need to run in a venv. To me, this is the biggest blocker to using Python for any non-trivial scripting (which is precisely the kind where I wouldn't want to use bash), but I'd like to know how others deal with it. C# scripts let you reference packages in a comment at the top of the file, for exa…
My principles is that I do not. If PyPI packages are needed, rewrite it in Rust (or Go or D or whatever allows me to use statically-linked libraries).
Python packages are fine for servers but not for CLI tools.
Re: Using Python for Scripting
#95> Python is installed on pretty much every machine > Python 3 is installed on basically every machine out there. > Python will work the same on all the machines you run your script on No, no, and no.
At work my machine has probably ten or more installations of Python hidden in various tools. I'm certainly not alone. So we could say "on average Python is installed on every machine". /s
Re: Using Python for Scripting
#96Earlier quoted context omitted.
You can specify requirements at the top of file and uv can run the script after automatically installing the dependencies. https://avilpage.com/2025/04/learn-python-uv-in-100-seconds....
This works really well in my experience, but it does mean you need to have a working internet connection the first time you run the script. # /// script # dependencies = [ # "cowsay", # ] # /// import cowsay cowsay.cow("Hello World") Then: uv run cowscript.py It manages a disposable hidden virtual environment automatically, via a very fast symlink-based caching mechanism. You can also add a shebang line so you can ex…
If not having a working internet connection is a concern, I would package your script into a shiv zipapp - https://shiv.readthedocs.io/en/latest/
Re: Using Python for Scripting
#97Earlier quoted context omitted.
You can specify requirements at the top of file and uv can run the script after automatically installing the dependencies. https://avilpage.com/2025/04/learn-python-uv-in-100-seconds....
As someone who writes a lot of python, I love uv, but isn't on nearly every system like python is, which is one of the arguments for using python here in the first place
The catch is that there could be a version mismatch between the version of Python installed on the end user's computer and the version on which the script was developed. This problem can be solved with uv, and there aren't really Python-native ways available.
Re: Using Python for Scripting
#98So they suggest to write scripts in Python rather than shell because Python is stable, probably installed on the target machine, has a big standard library, and is more readable. Many people do so. That's the bright side of Python. They should mention the dark side, or Why _not_ to use Python for scripting. First of all, the promise of easy portability breaks as soon as the script has dependencies. Try to install som…
Python relies on env variables to find where to load modules. Updating those variables is what venv does essentially.
Re: Using Python for Scripting
#99Earlier quoted context omitted.
It’s like Vim, you learn it once, and you keep using it forever once you’re used to it. I’m so thankful to see a flake.nix file in every single cool project on code forges.
Yea that's a common theme of excuses for both Rust and Nix. Wrong though, because most anyone who can use a computer at all can learn the basics of Vim. Seeing that flake.nix badge of complexity lets me know a project will be a nightmare to set up and will break every other week. It's usually right next to the Cargo.toml badge with 400 dependencies underneath.
To be honest I don't know what to say, you can use nix in many ways, and you don't even require to know the language.
The easiest entry-point is to just use it like a package manager, you install nix (which is just a command...) and then you have available the whole set of packages which are searchable from here: https://search.nixos.org/packages
nix-shell is just to download&add programs temporary to your PATH.
I don't feel that this is harder than something like "sudo apt install -y xxxxx" but for sure more robust and portable, and doesn't require sudo.
If at some point you want to learn the language in order to create configurations or packaging software, it may require to check a lot more documentation and examples, but for this I think it's pretty straightforward and is not harder than any other package manager like aptitude, homebrew or pacman.
Re: Using Python for Scripting
#100Why not use Perl?
Because of its culture, and what it does to your brain.