Generate dedicated Python session event types

[stephentoub]

Summary

Python session events still used quicktype and collapsed payload members into one merged Data model, unlike the newer Go implementation. That made the language bindings inconsistent and increased the chance of naming conflicts as the runtime schema grows.

This change switches Python session-event generation to dedicated per-event payload dataclasses, matching the newer Go-style approach. SessionEvent.from_dict() now dispatches to typed payload classes, unknown events still round-trip through RawSessionEventData, and the Python runtime/tests were updated to handle the typed payload union.

The one non-obvious part is compatibility: the generator also restores legacy top-level helper exports and keeps arbitrary nested mappings in the Data shim as plain dicts so older callers do not break while the generated model becomes more structured.

Validation

• python -m pytest test_event_forward_compatibility.py test_commands_and_elicitation.py
• python -m pytest --ignore=e2e

[Copilot]

Pull request overview

This PR updates the Python SDK’s session-events generation to emit dedicated per-event payload dataclasses (instead of a single merged Data payload), and updates the Python runtime/tests to consume these typed payloads while retaining compatibility shims.

Changes:

• Replaced Python session-events quicktype generation with a custom generator that emits per-event payload dataclasses and dispatches in SessionEvent.from_dict().
• Updated Python session handling and tests to use typed payload classes (e.g., CommandExecuteData, ElicitationRequestedData) and validate legacy top-level exports + Data shim behavior.
• Preserved forward compatibility for unknown event types via SessionEventType.UNKNOWN + RawSessionEventData, plus added several legacy helper aliases.

Show a summary per file

File	Description
scripts/codegen/python.ts	Implements custom Python session-events codegen emitting per-event payload dataclasses, compatibility shims, and typed dispatch.
python/test_event_forward_compatibility.py	Extends forward-compat tests to cover legacy helper exports and Data shim dict-preservation behavior.
python/test_commands_and_elicitation.py	Updates tests to construct typed event payloads instead of using the legacy Data container.
python/copilot/session.py	Updates broadcast event handling to cast event.data to the appropriate generated payload dataclass before accessing fields.

Copilot's findings

• Files reviewed: 4/5 changed files
• Comments generated: 2

[github-actions]

Cross-SDK Consistency Review

This PR successfully brings Python session events in line with the Go and .NET approach — using dedicated per-event payload dataclasses (AssistantMessageData, PermissionRequestedData, etc.) rather than the previous generic merged Data model. This is a positive consistency improvement.

Summary by SDK:

SDK	Session event access pattern	Status
Go	Type assertion: event.Data.(*AssistantMessageData)	✅ Already uses per-event types
.NET	Strongly-typed per-event Data property	✅ Already uses per-event types
Python	isinstance() / cast() with AssistantMessageData	✅ Aligned by this PR
TypeScript	Discriminated union with anonymous inline types	✅ By design (structural typing)

One minor finding: The Python snippet in docs/setup/local-cli.md was not updated to reflect the new patterns introduced by this PR (see inline comment). All other Python examples (README, docstrings) were updated correctly.

Overall the PR is a good step for consistency. 👍

Generated by SDK Consistency Review Agent for issue #1063 · ● 488.3K · ◷

[github-actions]

Generated by SDK Consistency Review Agent for issue #1063 · ● 488.3K

[SteveSandersonMS]

Rather than the cast, can we recommand a pattern like:

if isinstance(event.data, AssistantMessageData):
     print(f"Assistant: {event.data.content}")  # type-checker narrows automatically
 elif isinstance(event.data, SessionErrorData):
     print(f"Error: {event.data.message}")

[SteveSandersonMS]

Generally looks good to me, would be interesting to run it by @brettcannon if you want more authoritative Python feedback.