Scripting

• When to Use Python Over Bash

  When to use python over bash is really a question of when to use bash. Python is a general-purpose language that can handle just about anything you throw at it. Bash, on the other hand, has a very specific sweet spot. Once you understand that sweet spot, the decision makes itself.

  What Bash Actually Is

  Bash is an interactive command interpreter and scripting language, created in 1989 for the GNU project as a free software alternative to the Bourne shell. It pulled in advanced features from the Korn shell and C shell, and it’s been commonly used by Unix and Linux systems ever since.

  What makes Bash unique is its approach to data flow programming. Files, directories, and system processes are treated as first-class objects. Bash is designed to take advantage of utilities that almost always exist on Unix-based systems. So think of tools like awk, sed, grep, cat, and curl. Another important thing to know when writing effective Bash scripts, you also need to understand the pipeline operator and how I/O redirection works.

  A good Bash script will look something like this:

  #!/bin/bash
  set -euo pipefail
  
  LOG_DIR="/var/log/myapp"
  DAYS_OLD=30
  
  find "$LOG_DIR" -name "*.log" -mtime +"$DAYS_OLD" -print0 |
    xargs -0 gzip -9
  
  echo "Compressed logs older than $DAYS_OLD days"
  

  Simple, portable, does one thing well. That’s Bash at its best.

  Where Bash Falls Short

  Bash isn’t typed. There’s no real object orientation. Error handling is basically set -e and hoping for the best. There’s no try/catch, no structured exception handling. When things go wrong in a Bash script, they tend to go wrong quietly or spectacularly, with not much in between.

  Python, by contrast, is optionally strongly typed and object-oriented. If you want to manipulate a file or a system process in Python, you wrap that system entity inside a Python object. That adds some overhead, sure, but in exchange you get something that’s more predictable, more secure, and scales well from simple scripts to complex logic.

  Here’s that same log compression task in Python:

  from pathlib import Path
  import gzip
  import shutil
  from datetime import datetime, timedelta
  
  log_dir = Path("/var/log/myapp")
  cutoff = datetime.now() - timedelta(days=30)
  
  for log_file in log_dir.glob("*.log"):
      if datetime.fromtimestamp(log_file.stat().st_mtime) < cutoff:
          with open(log_file, "rb") as f_in:
              with gzip.open(f"{log_file}.gz", "wb") as f_out:
                  shutil.copyfileobj(f_in, f_out)
          log_file.unlink()
  

  More verbose? Absolutely. But also more explicit about what’s happening, easier to extend, and much easier to add error handling to.

  The Performance Question

  In some cases, performance genuinely matters. Think high-frequency trading platforms, edge devices, or massive clusters. Bash scripts excel here because there’s almost zero startup overhead. Compare that to Python, which needs to load up the interpreter before it can start executing code. You’re going from microseconds to milliseconds, and sometimes that matters.

  But startup time is just one factor. When you compare the actual work being done, Python can pull ahead. String manipulation on structured data? Python wins. Parsing JSON, YAML, or any structured format? Python’s core libraries are written in C and optimized for exactly this kind of work. If you find yourself reaching for jq or yq in a Bash script, that’s a strong signal you should be using Python instead.

  The Guidelines People Throw Around

  You’ll see a common guideline online: if your script exceeds 100 lines of Bash, rewrite it in Python. But a lot of veterans in the industry feel like that cutoff is way too generous. Experienced engineers often put it at 50 lines, or even 25.

  Another solid indicator: nested if statements. Some people say “deeply nested” if statements, but let’s be honest, more than one level of nesting in Bash is already getting painful. Python handles complex branching logic far more gracefully, and you’ll thank yourself when you come back to maintain it six months later.

  Unit Testing Tells the Story

  You can do unit testing with Bash. BATS (Bash Automated Testing System) exists, and ShellCheck is useful as a lightweight linter for catching bad practices. But despite these tools, Python’s testing ecosystem is on another level entirely. It’s fully mature with multiple frameworks, excellent mocking capabilities, and the ability to simulate network calls, external APIs, or system binaries. Complex mocking that would be difficult or impossible in Bash is straightforward in Python.

  If your script needs solid testing or if it’s doing anything important, that’s a strong vote for Python.

  Bash’s Biggest Win: Portability

  So what does Bash actually win at? Portability. When you think about all the dependencies Python needs to run, Bash is the clear winner. You’re distributing a single .sh file. That’s it.

  With Python, you have to ask: Does Python exist on this machine? Is it the right version? You’ll need a virtual environment so you don’t pollute system Python. You need third-party libraries installed via a package manager; and please friends, remember that we don’t let friends use pip. Use Poetry or uv. Pip is so bad that I’d honestly argue that Bash not having a package manager is better than Python having pip. At least Bash doesn’t pretend to manage dependencies well.

  If you want something simple, something that can run on practically any Unix-based machine without setup, Bash is your answer. Even Windows can handle it these days through WSL, though you’re jumping through a few hoops.

  TLDR

  The decision is actually pretty straightforward:

  • Use Bash when you’re gluing together system commands, the logic is linear, it’s under 50 lines, and portability matters.
  • Use Python when you’re parsing structured data, need error handling, have branching logic, want proper tests, or the script is going to grow.

  If you’re reaching for jq, writing nested if statements, or the script is getting long enough that you’re losing track of what it does… it’s time for Python.

  I think in a future post we might look at when Go makes sense over Bash. There’s a lot to cover there about compiled binaries, but for now, hopefully this helps you make the call next time you’re wondering what to start your scripting with.

  Mar 10, 2026 / DevOps / Programming / Python / Bash / Scripting

  Enjoyed this?