Every Python tutorial introduces list comprehensions as a “cleaner” way to write loops. What they don’t tell you is that list comprehensions are also faster sometimes significantly because they’re optimized at the bytecode level.

When I was building my scraper, I had a loop that filtered job listings by keyword. It worked, but it felt sluggish. After rewriting it as a comprehension, not only did the code shrink from 8 lines to 1, it ran noticeably faster on larger datasets.

# Before — verbose, slower
filtered = []
for job in job_listings:
    if "Python" in job["skills"]:
        filtered.append(job["title"])

# After — clean and faster
filtered = [job["title"] for job in job_listings if "Python" in job["skills"]]

Here is a scenario. You need to process 500,000 rows from a CSV file. If you load them all into a list, your machine will either crawl or crash. Generators solve this by yielding one item at a time, keeping memory usage near zero regardless of dataset size.

I learned this the hard way when my laptop fans started sounding like a helicopter engine during a data pipeline task. The fix was a single keyword: yield.

def read_large_csv(filepath):
    with open(filepath, "r") as f:
        for line in f:
            yield line.strip().split(",")

for row in read_large_csv("500k_jobs.csv"):
    process(row)  # Only one row in memory at a time

Decorators confused me for an embarrassingly long time. I thought they were some advanced black magic reserved for framework authors. Turns out, a decorator is just a function that takes another function as input and returns a modified version of it.

Once I understood that, I started using them everywhere for logging, timing, retry logic, and access control.

import time

def timer(func):
    def wrapper(*args, **kwargs):
        start = time.time()
        result = func(*args, **kwargs)
        print(f"{func.__name__} took {time.time() - start:.2f}s")
        return result
    return wrapper

@timer
def fetch_data(url):
    # Your slow API call here
    pass

Files, database connections, network sockets. Every time you open one of these without properly closing it, you leave a door open that eventually causes memory leaks, corrupted files, or deadlocks.

The with statement is Python’s way of saying: I’ll handle the cleanup, you focus on the logic. Before I understood context managers, I had a project that silently corrupted output files because I never explicitly closed them.

# Risky — what if an exception hits before close()?
f = open("output.csv", "w")
f.write(data)
f.close()

# Safe — closes automatically, even on exceptions
with open("output.csv", "w") as f:
    f.write(data)

Early in my Python journey, I wrote functions with a fixed number of parameters. Then I needed to pass extra options, and suddenly I was refactoring half the codebase just to add one argument.

*args and **kwargs let your functions accept any number of positional or keyword arguments. This makes them dramatically more reusable, especially when building wrappers, utility functions, or automation tools.

def log_event(event_name, *args, **kwargs):
    print(f"Event: {event_name}")
    print(f"Details: {args}")
    print(f"Metadata: {kwargs}")

log_event("file_processed", "report.pdf", status="success", pages=12)

I used to treat try/except blocks as something you bolt on at the end, after the “real” code is done. That mindset cost me hours of debugging sessions because production data is messy, APIs time out, and files go missing.

Good exception handling is not just about preventing crashes. It is about writing code that tells you exactly what went wrong, where, and why. The difference between a silent failure and a useful error message is often just one well-written except block.

import logging

def fetch_user_data(user_id):
    try:
        response = api.get(f"/users/")
        response.raise_for_status()
        return response.json()
    except requests.Timeout:
        logging.error(f"Timeout fetching user ")
    except requests.HTTPError as e:
        logging.error(f"HTTP error: {e.response.status_code}")
    return None

Raise your hand if you have ever written a class with an __init__ method that just assigns a dozen self.attribute = attribute lines. That is boilerplate Python made obsolete in version 3.7.

Dataclasses auto-generate __init__, __repr__, and __eq__ for you based on annotated fields. For any class whose primary job is holding data, this is the right tool.

from dataclasses import dataclass, field
from typing import List

@dataclass
class JobListing:
    title: str
    company: str
    salary: int
    skills: List[str] = field(default_factory=list)

job = JobListing("ML Engineer", "Acme Corp", 120000, ["Python", "PyTorch"])
print(job)  # Clean __repr__ for free

For years, I concatenated file paths like this: base_dir + "/" + "data" + "/" + filename. On Windows, this breaks. With os.path, it works but reads like hieroglyphics.

Pathlib, introduced in Python 3.4, treats file paths as objects rather than strings. It is cross-platform by default, supports method chaining, and reads like plain English.

from pathlib import Path

# Old way — fragile and platform-dependent
import os
output_path = os.path.join(os.getcwd(), "data", "output", "results.csv")

# New way — clean and cross-platform
output_path = Path.cwd() / "data" / "output" / "results.csv"
output_path.parent.mkdir(parents=True, exist_ok=True)
output_path.write_text(results)