importlib

A backport of Python 2.7's import_module() function for Python 2.5, 2.6, and 3.0.

Library
PyPI
v1.0.4
1stars
Python Software Foundation License

Repository Health

Pre-computed score based on development activity, maintenance, community, maturity, and trend momentum.How we score it →
16/100Needs Attention
Development Activity0
Maintenance0
Community4
Maturity60
Momentum0

Technical Analysis

AI-assessed by reading the actual repository — architecture, code quality, innovation, and documentation.How we score it →
18/100Needs Attention
Architecture15
Code Quality10
Innovation20
Learning Curve25

This package repackages the import_module() function exactly as it shipped in Python 2.7’s standard library, making it available to projects still running Python 2.5, 2.6, or 3.0 — interpreter versions that predate importlib’s inclusion (or maturity) in the standard library. The code in the distributed package is a verbatim copy of the CPython 2.7 implementation, with no independent logic added on top.

The project is explicitly unmaintained: the README carries a “No Maintenance Intended” badge, since every Python version it targets reached end of life years ago. It exists purely as a stopgap for legacy codebases that cannot upgrade their interpreter but still want the import_module() call signature.

What You Get

  • The import_module() function, copied verbatim from the Python 2.7 standard library implementation.
  • A distutils-based setup.py that conditionally includes the backport package body only on affected interpreter versions.
  • PSF-licensed source code, matching the license of the CPython code it copies from.
  • A README that documents the project’s end-of-maintenance status up front.

Common Use Cases

  • Supporting import_module() on legacy Python 2.5/2.6 deployments that cannot be upgraded.
  • Providing import_module() compatibility for early Python 3.0 codebases that predate its stdlib inclusion.
  • Satisfying old requirements.txt pins that still reference importlib as a transitive dependency.
  • Reading a historical reference copy of the Python 2.7 import_module() implementation without installing that interpreter.

Under The Hood

Architecture There is no application architecture to speak of: the repository holds only packaging metadata (setup.py, MANIFEST.in, README.rst, LICENSE). The actual importlib/ package directory that setup.py conditionally installs is excluded from version control via .gitignore, so the distributed sdist/wheel is built from source that is not present in the GitHub repository itself — only the packaging shell is tracked.

Tech Stack setup.py uses distutils.core.setup() directly (no setuptools, no pyproject.toml, no build backend), targeting Python 2.3 through 3.0 per its version classifiers. It has zero third-party dependencies and no build tooling beyond the standard library’s distutils module, consistent with a package first published in the early 2010s.

Code Quality No test files, test framework, or CI configuration exist anywhere in the repository. There is no type information (the package predates PEP 484), no linter configuration, and no contributor documentation beyond the README’s maintenance notice. Code quality cannot be meaningfully assessed beyond noting the complete absence of automated verification.

API Design The public surface is a single function, import_module(name, package=None), identical to the one later standardized in every supported Python version. That makes it trivially easy to learn — there is nothing to learn beyond what the standard library itself documents — but it also means the package adds no value beyond making a stdlib function available a few interpreter versions early, a need that no longer exists for any currently supported Python release.

Join founders buildingwith open source

Opinionated takes, migration guides, cost-saving tips, and insights from the open source ecosystem.

Subscribe on Substack
Join 750+ subscribers

Search