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 makes a positive consistency improvement: Python session-event generation now uses per-event typed dataclasses (matching Go's approach), replacing the previous merged Data model. The overall cross-SDK picture looks good.

What's consistent

• Python ↔ Go alignment: Both now use per-event typed data structs, and event dispatch now uses explicit type casts (Python: cast(TypedClass, event.data) / Go: type assertions event.Data.(*TypedStruct)). ✅
• Public API signatures unchanged: send_and_wait, send, create_session etc. are untouched across all four SDKs. ✅
• Docs fix (local-cli.md): The two Go code samples are correctly updated to use type assertions on response.Data. ✅

Minor observation — Python example patterns

After this PR, the internal session.py uses cast(TypedClass, event.data) for type-safe access, but some user-facing docs still show the untyped pattern:

session.py docstring (line 1133):

>>> if response:
...     print(response.data.content)

README.md (lines 41, 77, 362, 366):

if event.type.value == "assistant.message":
    print(event.data.content)

These work correctly at runtime (Python duck typing), but response.data/event.data is now a typed union, so a type checker would flag direct attribute access without narrowing. The internal code correctly uses cast() — consider updating the docstring example and README snippets to demonstrate the same pattern, e.g.:

from typing import cast
from copilot.generated.session_events import AssistantMessageData

>>> if response:
...     print(cast(AssistantMessageData, response.data).content)

This is not a cross-SDK consistency blocker, just a suggestion to keep user-facing docs aligned with the typed approach the PR is introducing internally.

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