Development Methodology

Several projects in the CPython stdlib follow this methodology for development:

• importlib.resources
• importlib.metadata
• zipfile.Path

These projects are maintained primarily in their external repositories (sometimes referred to as "backports"). Development is preferred in the external repositories due to a host of advantages:

• The test suite runs under pytest, a richer test runner, affording more sophisticated behaviors even when running unittest-based tests.
• Maintenance follows best practices as defined by the skeleton used by hundreds of other projects, and deriving value from common concerns such as updating support for Python versions.
• Extra checks are performed to ensure consistent formatting, style, and safety (ruff, mypy, ...).
• Doctests are checked.
• Performance benchmarks can be measured and tested.
• Code is tested against all supported Python versions.
• Changes can be released quickly and get rapid feedback, shifting left the lifecycle.

As a result, this preference means that the external projects are "upstream" of Python and code is synced "downstream" into Python's stdlib.

These projects still accept contributions downstream in Python.

Regardless of the original source of the contribution, these two codebases should be kept in close sync and utilize techniques to minimize the diffs between the two targets. Here are some of the ways these projects achieve that minimum variance:

• Code in the stdlib should be partitioned into folders pertaining to the shared functionality. That means that the abstract base classes for importlib resources should live in importlib.resources.abc and not importlib.abc. That is also why zipfile.Path is implemented as zipfile._path.Path.
• The external project should implement "compatibility" shims in separate modules or (preferably) packages. For example, importlib_resources exposes future and compat packages for the external-specific behaviors. This behavior is excluded in the port to CPython.
• Each project keeps a cpython branch that tracks the state of the code that keeps track of the code in the same layout as it appears in the stdlib, such that one can cp -r the contents in either direction and there should be no diff when projects are in sync.