Python Standard

StrictRule

Describes a single rule, its required value, and its rationale.

PythonStandard

Collects the current Python profile, required files, required docs, and strict rules.

ProfileName

Enumerates the supported standard profile names.

default_python_standard

Returns the current strict Python package profile.

default_standard

Returns the current profile by name. The default profile is python-package.

render_python_standard

Renders the current profile for human or machine use.

render_standard

Renders a named profile for human or machine use.

Profiles

python-package is the pure Python baseline. Native-backed projects use the python-native-wasm profile documented in Mixed Mode Standard. Native C++ projects use the cpp-library profile documented in C++ Standard. C# applications and host plugins use the csharp-app profile documented in C# Standard. Browser apps use the javascript-web-app profile, and Python-served browser apps use the python-js-app profile documented in JavaScript Web App Standard.

Schema Versioning

Contract versions may use dates, semantic identifiers, or hardware-style stepping names such as A0, A1, B0, or B1. Each contract must document compatibility rules. Optional additive fields are usually compatible when old parsers ignore unknown fields. Required, renamed, removed, or semantic changes are breaking.

JSON payload identity follows the JSON Contract Standard. Durable object payloads should use root type plus version, nested variants should use kind, and config-like or compatibility files may use a documented root schema field. Pydantic is an implementation and validation mechanism for Python and FastAPI-style services; exported Pydantic JSON Schema must still match the accepted contract docs and fixtures.

Python Runtime Window

The wn-dev-std reference package pins requires-python = ">=3.12,<3.13". This is a stability choice for the executable standards package so CLI behavior, Ruff, Pyright, Rack signoff, and generated metadata share one interpreter baseline. Downstream Python projects may choose a wider or newer runtime window when their compatibility contract and CI matrix prove it.

Design Document Status

HTML design docs must carry a machine-readable data-doc-status marker. Accepted pages describe current contract or standard behavior. Draft and proposal pages may guide active implementation, but release signoff must review them explicitly before treating them as accepted contract evidence. See Documentation Standard.

Compatibility Pruning

Repositories with known legacy names, environment variables, setup shims, or compatibility aliases should declare a [compatibility_pruning] table in dev-std.toml. The check scans the configured root for forbidden_patterns and reports file and line locations when old surfaces return. 

[compatibility_pruning]
root = ".."
forbidden_patterns = [
  "\\bWN_LIBZ_ROOT\\b",
  "\\bwn_pcb\\b",
]
excluded_parts = ["test_cases", "fixtures"]

Captured fixtures, generated outputs, and tool caches should be excluded deliberately. New compatibility shims need an explicit design reason and a signoff ratchet so they do not become permanent hidden API surface.

Public PR Hygiene

Public repositories should install the shared GitHub PR hygiene workflow and PR template from docs/templates/github/, then opt into local validation with a [pr_hygiene] table. The workflow requires a filled Linked issue: line that resolves to an existing same-repo issue, Conventional Commit form for PR titles and commit subjects, commit subjects of 72 characters or fewer, and no WIP, emoji, or AI-vendor attribution in PR metadata or commit messages. Reviewed public PRs should squash merge into main and avoid non-linear public history unless a project-specific release exception documents why branch history must be preserved. 

[pr_hygiene]
enabled = true