py

py is a small Python support library that grew out of the early pytest project, bundling a handful of cross-platform utilities: py.path for uniform local and SVN path objects, py.iniconfig for parsing .ini files, py.apipkg for lazy, explicit API control, and py.code for dynamic code generation and introspection. It is officially in maintenance mode — the project’s own README tells users not to adopt it for new code and instead points to the standalone successors (pathlib, iniconfig, apipkg) that absorbed each piece. It remains published mainly so that older packages and pinned environments that still import py continue to work.

What You Get

• py.path.local and py.path.svnwc — object-oriented, cross-platform path manipulation predating widespread pathlib adoption
• py.iniconfig — a minimal parser for .ini-style configuration files
• py.apipkg — a mechanism for declaring a package’s public API lazily, deferring submodule imports until first access
• py.code — internals for dynamic code compilation, traceback formatting, and introspection (later folded into pytest itself)
• A stable, dependency-free install that keeps decade-old codebases importing py working without modification

Common Use Cases

• Keeping old pytest plugins or internal tooling that still import py running without a rewrite
• Maintaining pinned CI environments where downgrading or removing py would break other pinned dependencies
• Reading legacy code that references py.path or py.code while planning a migration to pathlib/iniconfig/apipkg
• Auditing a dependency tree for an inherited, unmaintained transitive dependency before replacing it

Under The Hood

Architecture: py is organized as a namespace package (py/) with independent subpackages per concern — _path (local and SVN path objects), _iniconfig, _code (introspection and traceback formatting, ~800 lines in code.py), _log, _io, and _process (subprocess helpers) — wired together through py/__init__.py’s lazy apipkg-style export table rather than direct submodule imports, so each piece can be used independently without pulling in the rest. Tech Stack: pure Python 2/3-compatible code with zero third-party runtime dependencies, built with setuptools and setuptools_scm for version derivation; the pyproject.toml only declares build-system requirements, keeping the installed package dependency-free. Code Quality: the testing/ directory holds 31 test files mirroring the module layout (testing/path, testing/code, testing/io_, testing/log, testing/process), run via tox across multiple Python versions per tox.ini; the code predates modern type hints and uses classic Python 2-era idioms, and the README itself flags the project as frozen in maintenance mode with no further feature development. API Design: each module exposes a small, focused surface (e.g., py.path.local(...) mirrors pathlib.Path but predates it), which made py convenient in the pytest-2.x era; today the maintainers explicitly steer users toward the standalone pathlib, iniconfig, and apipkg packages that superseded these APIs.