The employable half of Python

What the job actually uses

Most Python courses spend their weeks on classes, inheritance and algorithm puzzles. Most Python jobs in this field spend their days on: read some data, reshape it, call an API, write the result somewhere, and make sure it does not fall over at 03:00.

The employable list is short.

• pathlib for files, because string paths break across operating systems.
• csv and json from the standard library, before reaching for anything bigger.
• requests or httpx for APIs, with a timeout on every single call.
• pandas or polars for tabular work.
• argparse so your script takes inputs instead of hard-coding them.
• logging instead of print, because a scheduled job with print statements produces output nobody sees.
• try / except naming a specific exception, never a bare except:.
• Virtual environments.

The bug that quietly destroys data

This one is worth more than a chapter of syntax.

df = pd.read_csv("customers.csv")
df["customer_id"].head()
# 0    7.0
# 1    42.0

Pandas inferred the column as a float because one row was empty. 007 is now 7.0. A postcode of 01234 is now 1234. An account number too long for a float loses its last digits silently, with no warning of any kind.

The fix is one argument, and typing it is a professional habit:

df = pd.read_csv(
    "customers.csv",
    dtype={"customer_id": "string", "postcode": "string"},
    keep_default_na=False,
)

The mechanism: identifiers look like numbers but are not numbers. Nothing arithmetic is ever done to them, and every operation that treats them as numeric loses information. This class of bug has broken payroll runs and lost hospital records, and no marketing page about learning Python will mention it.

“It worked in my notebook”

Notebooks keep state. Cells run in whatever order you clicked them, variables persist after you delete the cell that made them, and the thing that makes your code work may no longer exist anywhere in the file.

The discipline: restart the kernel and run all, before you believe any result. Do it before you show anyone anything. Half of the “I cannot reproduce it” conversations in data teams are this.

A script skeleton worth memorising

import argparse, logging, sys
from pathlib import Path
import pandas as pd

logging.basicConfig(level=logging.INFO,
                    format="%(asctime)s %(levelname)s %(message)s")

def clean(df: pd.DataFrame) -> pd.DataFrame:
    before = len(df)
    df = df.drop_duplicates(subset=["order_id"])
    logging.info("dropped %d duplicate orders", before - len(df))
    return df

def main() -> int:
    p = argparse.ArgumentParser()
    p.add_argument("--input", type=Path, required=True)
    p.add_argument("--output", type=Path, required=True)
    args = p.parse_args()

    df = pd.read_csv(args.input, dtype={"order_id": "string"})
    logging.info("read %d rows from %s", len(df), args.input)
    clean(df).to_csv(args.output, index=False)
    return 0

if __name__ == "__main__":
    sys.exit(main())

Every line of that is doing employable work: it takes arguments, it says what it did, it names its types, it returns an exit code a scheduler can read. A reviewer looking at this knows you have run something in production, or at least understand what production needs.

Environments, without the folklore

python -m venv .venv
source .venv/bin/activate      # Windows: .venv\Scripts\activate
pip install -r requirements.txt

That is the whole thing. uv does the same faster if you prefer. The point is that your project declares its dependencies in a file, so a colleague, or you in six months, can run it.

The free path covers everything: plain venv and pip, VS Code or VSCodium, Colab for anything needing a GPU. The paid options people assume they need (commercial Anaconda licences, PyCharm Professional) buy convenience, not capability.

The most underrated skill: reading someone else’s code

You will spend more time reading code than writing it, and almost nobody practises it deliberately. A method that works on any unfamiliar repository:

1. Find the entry point: the file with if __name__ == "__main__", or the route definitions, or whatever the README says to run.
2. Follow exactly one path from input to output. One request, one record, one file.
3. Ignore everything else, including the parts that look important.
4. Change one small thing and run it. What breaks tells you what depends on what.

An hour of this on a real open-source project teaches more than a week of tutorials, and it is precisely what your first month at a job will be.

Where pandas stops

Pandas holds everything in memory and copies aggressively, so on an ordinary laptop it starts struggling somewhere around a few gigabytes, and the effective ceiling is lower than your RAM, because an operation may need several copies at once. That is the honest threshold. Above it, the answers are polars, DuckDB over Parquet files, or moving the work into a database. Knowing the number is more useful than the vague claim that pandas is slow.