six

Six is a Python compatibility shim originally built to let a single codebase run unmodified on both Python 2 and Python 3. It ships as one pure-Python module (six.py) that can be dropped directly into a project, and it normalizes the API differences that broke code across the 2/3 split: string and integer type aliases, moved and renamed standard-library modules, iterator protocol differences, metaclass syntax, and the print statement/function split.

Since Python 2’s end-of-life, six’s practical role has shifted: rather than being adopted by new projects, it persists mainly as a transitive dependency pulled in by setuptools and a long tail of older packages that still import six.moves or six.string_types for legacy compatibility. Its API is frozen and stable, and maintenance work is now almost entirely bug fixes and CI matrix upkeep across current Python and OS versions rather than active feature development.

What You Get

• A single dependency-free six.py module you can vendor directly into your project
• Type aliases (string_types, integer_types, text_type, binary_type) that resolve correctly on both Python 2 and 3
• six.moves proxy modules that resolve renamed or relocated stdlib modules like urllib, queue, and configparser to their correct location per interpreter
• Decorators and helpers (add_metaclass, python_2_unicode_compatible, with_metaclass) for writing metaclass and unicode-handling code that works unmodified on both versions
• A print_ function wrapper for code that must run under both Python 2’s print statement and Python 3’s print() function

Common Use Cases

• Maintaining a legacy library that still needs to run on Python 2.7 while also supporting current Python 3 releases
• Depending indirectly on six via setuptools or another package that hasn’t dropped it as a transitive dependency
• Porting an old Python 2 codebase to Python 3 incrementally, using six as a compatibility bridge during the transition
• Writing test or build tooling that has to interoperate with packages published years ago against the Python 2 API

Under The Hood

Architecture

six.py is a single flat module with no subpackages. It uses a data-driven table of MovedAttribute/MovedModule descriptor instances registered onto proxy classes (moves and moves.urllib), relying on the descriptor protocol (_LazyDescr.get) to defer and cache imports until first access — the module simulates a package tree via sys.modules manipulation (_import_module, _LazyModule) rather than real subpackages. There is no dependency injection; most compatibility is a top-level conditional branch keyed on PY3/PY2, with the lazy proxy pattern reserved for the harder case of renamed stdlib modules. Changing the core _LazyDescr contract would ripple through every entry in the _moved_attributes and _urllib_parse_moved_attributes tables, since they all share its get/caching behavior.

Tech Stack

Pure Python with zero runtime dependencies — a single six.py file and no install_requires beyond the stdlib. Packaged with a classic setup.py/setup.cfg that falls back from setuptools to distutils if setuptools is unavailable, deliberately avoiding a circular bootstrap dependency since six is itself a dependency of setuptools. Test dependency is pytest, declared in tox.ini. CI runs the test suite across CPython 2.7 and 3.6 through 3.14 plus PyPy 2.7/3.11, on Ubuntu, Windows, and macOS via GitHub Actions, alongside a dedicated flake8 lint environment.

Code Quality

test_six.py combines unittest.TestCase classes with pytest fixtures, parametrization, and pytest.raises/pytest.warns for exception and deprecation-warning assertions, with dedicated cases for each compatibility shim (moved modules, metaclass helpers, iterator functions). Error handling favors explicit try/except ImportError fallbacks over silently swallowed exceptions, as seen in the setup.py setuptools/distutils fallback and the MAXSIZE computation. Naming stays terse and consistent with stdlib conventions (iteritems, add_metaclass); there are no type hints, consistent with targeting Python 2.7 compatibility. Linting is enforced via flake8 in CI/tox, and the test matrix runs against every supported interpreter version.

API Design Six’s ergonomics come from unifying disparate Python 2/3 porting idioms behind a small, memorable API surface (six.PY2, six.moves.urllib, six.add_metaclass) rather than any novel technical mechanism — the lazy attribute-proxy technique it uses predates six and is a well-known Python idiom. Its distinguishing design choice is being a single importable, vendorable file with zero dependencies, which made it trivially embeddable into any project during the Python 2-to-3 transition — a packaging and distribution choice more than an algorithmic one.