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]

SDK Consistency Review ✅

This PR is primarily a consistency improvement that aligns Python with Go — good work!

Cross-SDK Event Data Access Patterns

After this PR, all four SDKs use language-idiomatic approaches for typed event data access:

SDK	Event data access pattern
Go	event.Data.(*copilot.AssistantMessageData) (type assertion / type switch)
Python	cast(AssistantMessageData, event.data) (explicit typing cast)
.NET	evt is AssistantMessageEvent msg (polymorphic pattern matching)
TypeScript	event.data.content after narrowing on event.type (discriminated union)

These are all consistent in intent (you must explicitly narrow to a typed payload) while being idiomatic for each language.

Minor Observation

The updated docstrings in session.py use event.type.value == "assistant.message" (comparing enum .value to a string literal), while python/README.md uses the cleaner typed enum comparison pattern. For consistency within the Python docs, it may be worth updating the docstring examples to match the README style:

# Less idiomatic (current docstring style)
if event.type.value == "assistant.message":

# More idiomatic (consistent with README style)
if event.type == SessionEventType.ASSISTANT_MESSAGE:

This is a minor nit and doesn't affect correctness or cross-SDK consistency.

Docs Fix

The docs/setup/local-cli.md fix (adding nil check and proper type assertion for the Go example) is a correctness improvement — the old *response.Data.Content was accessing the pre-refactor generic model.

No cross-SDK feature parity concerns found in this PR.

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