Emit Python JSON-Schema models as dataclasses with transfer type converters

[bergundy]

Stacked on #124 (ts-transfer-type-encoding) — the base is that branch, not main. Merge after #124.

Summary

Generated Python JSON Schema models now use slotted, keyword-only dataclasses instead of pydantic.BaseModel. Their wire contract lives in generated transfer type converters discovered by Temporal's default data converter, so consumers no longer need Pydantic or a custom Pydantic data converter.

@_transfer_type_convertible(_UserTransferTypeConverter)
@dataclasses.dataclass(slots=True, kw_only=True)
class User:
    name: str
    location: Location | None = None

The generated API now follows these rules:

• Optional or nullable values are annotated as T | None.
• Schema defaults are materialized through mutable properties backed by private presence fields. Reading an unset property returns its schema default, assigning stores an explicit value, and del model.field restores the unset state.
• Default constants are no longer part of the generated public API.
• Unknown object members are preserved in additional_properties.
• Validation failures aggregate into the shared ValidationError / Violation { path, reason } shape.
• ValidationError and Violation are re-exported from every generated package root, so consumers do not import the private _definitions module.
• The default Temporal converter performs the generated model-to-wire and wire-to-model conversion.

This keeps materialized reads separate from wire presence: an unset default-bearing property reads as its schema default but remains omitted when serialized, while an explicitly assigned value is emitted.

Correctness fixes found during the rewrite

The dataclass conversion exposed several existing cross-language and wire-compatibility gaps. This branch also:

• validates temporal values consistently on parse and serialization, including Python 3.10 sub-second behavior, year bounds, oversized duration components, naive datetimes, and invalid timedeltas;
• rejects non-finite JSON numbers and normalizes integral closed numeric values;
• validates array elements inside unions, rejects values matching no union branch, validates before serializer dispatch, and preserves nested serialize-side error aggregation;
• prevents authored property names from shadowing converter locals, builtins, imports, or synthesized module names;
• uses tuple membership for const/enum checks and keeps generated Python Ruff-clean;
• enforces a TypeScript string array element's own constraints;
• compares canonical wire bytes in the Python fixture suite instead of relying on parsed-value equality; and
• runs the Python samples on the declared Python 3.10 floor and adds ruff check to the repository validation script.

Every generated-output change was made in the generator and regenerated with cargo build-json-examples --lang python.

Review

Best reviewed one commit at a time, starting at 93f55d8. The final generated-default API is concentrated in:

• 4a2ab03 — materialize schema defaults through properties;
• 988fc7e — retain T | None union syntax;
• 4cbd8f9 — clear explicit values with property deleters;
• e439348 — compact the Unreleased changelog entry; and
• 559eb71 — export validation error types from generated package roots.

Verification

./scripts/validate.sh passes under the nvm-managed Node 26 runtime. This includes:

• Rust formatting and the full cargo test --features advanced suite;
• Python tests on 3.13 and the declared 3.10 floor;
• BasedPyright with zero errors and warnings;
• Ruff check and format verification;
• TypeScript typechecking, Vitest, and Prettier; and
• Go formatting and tests for both sample tiers.

Known follow-up

src/generator/proto/python.rs still emits the bare transfer_type_convertible decorator for WIT-generated Python. Its circular static typing issue is separate from this JSON Schema rewrite and remains follow-up work.

[tconley1428]

This seems to be leaking json stuff from the backend. I believe the backend is capable of adding additional needed imports/exports in the model file via RenderedModelFragments but this is an extension to be able to add top level init exports. Potentially a separate backend call is also possible but probably less ideal due to shared logic.