Removing Python's Dead Batteries (in just 5 years)

Episode Deep Dive

Guests Introduction and Background

Brett Cannon is a long-time Python core developer (19+ years) and a member of the Python Steering Council since its inception. He works at Microsoft as the dev manager for the Python experience in Visual Studio Code. He has been deeply involved in Python’s migration to GitHub and has helped shape important proposals like PEP 594.

Christian Heimes has been a Python core developer for over 14 years. He works on security engineering at Red Hat, focusing on areas such as identity management and security in Linux environments. He maintains parts of Python’s security features, including SSL and OpenSSL compatibility, and co-authored PEP 594 with Brett Cannon.

What to Know If You're New to Python

If you’re somewhat new to Python, here are a few quick pointers to help you get more out of this discussion on trimming older modules (a.k.a. "dead batteries") from the Python Standard Library:

• Python “batteries included” means it ships with a large set of built-in modules and tools.
• Deprecation means a module is on its way out but still usable until a future version fully removes it.
• PEP stands for Python Enhancement Proposal, which is how major changes are proposed and approved in Python.
• Many older modules have modern replacements on PyPI or via pip that you can install separately.

Key Points and Takeaways

1. PEP 594: Removing Outdated Modules from the Standard Library
   This core proposal, authored by Christian Heimes and guided by Brett Cannon, aims to remove “dead batteries” that are no longer widely used, unmaintained, or have better third-party equivalents. It helps streamline Python by cutting down on old or underused modules, such as nntplib or crypt, which can introduce security and maintenance overhead.

   • Links / Tools:
     • PEP 594
     • PyPI

2. Batteries Included: Then vs. Now
   Historically, the Standard Library had to ship as many tools and modules as possible, since Python predated modern package managers and easy internet distribution. With the rise of tools like pip and over 300k packages on PyPI, “batteries included” means something different today, and the large standard library may no longer be essential for every feature.

   • Links / Tools:
     • pip

3. Timeline for Deprecation and Removal
   The removed modules are first marked as deprecated (in Python 3.11), continue to exist but warn in Python 3.12, and finally vanish in Python 3.13 (scheduled roughly for 2024). This approach ensures users have ample time to migrate to third-party libraries or vendor their own copy of the code under Python’s permissive license.

   • Links / Tools:
     • Python Release Schedule

4. What Happens if You Need a Removed Module
   Even if a module is removed from the Standard Library, you can continue using it by either copying the code into your app (vendorizing it) or installing it separately from PyPI if someone maintains a standalone version. The PSF license makes such reuse completely valid.

   • Links / Tools:
     • Python License

5. GitHub Migration and Maintenance Burden
   Brett Cannon led Python’s move from self-hosted services to GitHub for version control and pull requests. One motivator for removing old modules is to reduce developer overhead—Python’s large library makes it harder to manage 1,600+ open pull requests. By archiving underused modules, contributors can focus on the ones that truly matter.

   • Links / Tools:
     • CPython GitHub Repo

6. Security Perspective
   Christian Heimes highlighted that many outdated modules present a security risk because they are under-tested or rely on insecure defaults (e.g., crypt or certain URL parsing code). Removing these prevents breakage in CI builds and reduces the attack surface for Python users.

   • Links / Tools:
     • OpenSSL

7. Where the Standard Library is Headed
   A broader conversation around what belongs in the standard library is underway. Should it only include the minimal set of modules essential for bootstrapping, or remain comprehensive? This discussion ties into potential “lite” Python distributions and WebAssembly builds, ensuring Python remains relevant in diverse environments.

   • Links / Tools:
     • Pyodide (Python in the browser)
     • WASM / WebAssembly

8. WebAssembly and Modern Deployments
   Brett and Christian have been compiling CPython to WebAssembly so Python can run inside browsers and on edge platforms. This requires stripping out pieces of the library that can’t function in the sandboxed environment or dealing with advanced bridging, such as how to manage threads or system calls in Node.js.

   • Links / Tools:
     • CPython-on-WebAssembly (EthanHS REPL)
     • Node.js

9. Historical Insight: Maintaining the Past
   The conversation highlighted unique older modules (e.g., nntplib for Usenet, telnetlib) that date back to when Python had to support dial-up, non-browser internet usage. Many are simply no longer relevant, and the CI overhead of testing them (e.g., needing external, now-flaky servers) is a burden.

   • Links / Tools:
     • NNTP (RFC 977 reference)

10. Community Feedback and Adjustments
    While PEP 594 is approved, the team remains open to reconsidering if there’s widespread outcry. Several modules (e.g., wav/wave) were initially threatened but stayed after feedback. This underscores Python’s tradition of thoroughly discussing changes and adjusting based on community input.

• Links / Tools:
  • wave Module (docs)

Interesting Quotes and Stories

Brett Cannon on the security aspects of old libraries:
“The volume [of old modules] there also kind of causes an extra overload… It’s really just about who is benefiting from us carrying this forward.”

Christian Heimes on removing nntplib:
“We used to rely on external NNTP servers for tests. They often fail or vanish, and it blocks the entire CI chain… it’s just not worth it.”

Both on the future of Python in browsers:
“It’s possible to run Python in WebAssembly, and once you do that, you can start to embed it in places like VS Code, or you can even do a mobile approach—maybe an offline progressive web app.”

Key Definitions and Terms

• PEP (Python Enhancement Proposal): A design document providing information to the Python community or describing a new feature for Python or its processes.
• Deprecation: The status given to features or modules that are still available but are planned for removal in a future release.
• NNTP: Network News Transfer Protocol, an old protocol for reading and posting Usenet articles.
• WebAssembly (WASM): A low-level bytecode for the web, allowing languages like Python, C++, and Rust to run in a browser or edge environment at near-native speed.

Learning Resources

If you are new to Python and want a proper introduction, consider these resources from Talk Python Training.

• Python for Absolute Beginners: Great for anyone brand new to Python, covering core language concepts in a beginner-friendly way.
• Python Memory Management and Tips: Useful if you want to understand how the standard library ties in with Python’s memory model and performance.
• Modern APIs with FastAPI and Python: Explore how new frameworks and external packages are likely better than older built-in modules for web-related tasks.

Overall Takeaway

PEP 594 signals a significant move toward modernizing Python by removing underused, outdated, or unmaintained modules from the Standard Library. This streamlining improves maintainability, security, and Python’s ability to adapt—especially for emerging platforms like WebAssembly. For Python’s future, the emphasis will remain on flexibility, community feedback, and embracing modern package management rather than shipping every possible module by default. While some modules are departing, Python continues to grow more robust, and there are always clear options—either in PyPI or through vendorizing—to fill any gaps for specialized needs.