Why Python's Batteries Included Is Outdated

Why Python's 'Batteries Included' Is Outdated

You’ve probably heard the phrase a thousand times: Python comes with “batteries included.” It means the standard library is so vast, you can build almost anything without installing extra packages. For years, this was a selling point. But let’s be honest—flying that flag today feels like showing up to a hackathon with a flip phone.

Don’t get me wrong. I love Python. I use it every day. But the idea that its standard library covers modern development needs is more myth than reality now. And holding onto that myth might actually be hurting your projects.

The standard library was built for a different era

The core of Python’s standard library stabilized around the late 1990s and early 2000s. Back then, web frameworks were exotic, machine learning was academic, and asynchronous programming was for C++ wizards. So what did Python include? http.server (good for testing, bad for production), sqlite3 (great for local storage, not your SaaS backend), and xml.etree.ElementTree (handy for 2005’s tech stack).

Fast forward to 2025. Your typical PythonSkillset project involves a REST API, a database connection pool, async endpoints, and maybe some cloud SDK. The standard library gives you http.server (single-threaded, synchronous) and urllib (which makes you write request handlers like it’s 1998). Meanwhile, requests and FastAPI are what everyone actually uses.

“Batteries included” now means “uninstall first”

Here’s a real-world example. You start a new Python project. You create a virtual environment, install pytest (because unittest is painful), black (because formatting), mypy (because type hints without checking aren’t helpful), and httpx or aiohttp (because urllib is, let’s say, verbose). Then you add a framework like Django or FastAPI. Suddenly, your requirements.txt is 20 lines long.

Is that a problem? Not really. Package management is good now. But it exposes the lie: the “batteries” aren’t enough for most real-world work. They give you a toy with a dead battery—you still need to buy the real ones.

The real cost: security and maintenance

The standard library is huge, and that’s a maintenance burden. Every new Python version ships with dozens of modules that receive minimal updates. telnetlib? Deprecated in 3.11. distutils? Gone. optparse? Largely replaced by argparse (which is fine, but you get the point). Some modules like imghdr, sndhdr, and formatter were removed recently without fanfare.

When you rely on batteries included, you’re trusting that the Python core team will keep those batteries fresh. Spoiler: they won’t. They can’t—they have to balance stability with innovation. Meanwhile, the community libraries you actually use (pandas, numpy, requests, flask) are updated weekly, with security patches and modern features.

What Python should advertise instead

Python’s real strength isn’t the standard library anymore. It’s the ecosystem. The fact that you can pip install almost anything. That’s what makes Python powerful. The standard library is now a baseline—a way to avoid requiring dependencies for trivial tasks (parsing JSON, reading CSV files, basic math). But calling it “batteries included” sets false expectations.

Here’s a better slogan: “Python: Start coding in five seconds, install the good stuff in five minutes.” That’s honest. That’s useful. That’s what PythonSkillset developers already know.

What should Python do?

First, the core team should stop pretending the standard library covers modern use cases. Deprecate old modules faster. Shrink the library to essential building blocks. Leave the batteries to the community.

Second, embrace that pip and PyPI are the real standard library. Make it easier to point beginners to requests instead of urllib. Promote pytest over unittest in the official docs.

Third, stop treating “batteries included” as a feature worth boasting about. It’s not 2000 anymore. If I need a battery, I’ll install one that’s not corroded.

Bottom line: Python’s standard library is a safety net, not a toolbox. It gets you started, but if you’re building anything serious, you’ll reach for the community packages. That’s fine. That’s modern Python. But let’s stop pretending the old battery pack is still cutting edge. It’s time to evolve the story.