Python: fix(core): accept a bare container type as an edge target for a parameterized output

[Anish Mehta (anishmehta24)]

Motivation & Context

A handler that takes a plain list (or dict, tuple, Sequence) can't receive a parameterized output from an upstream executor. The workflow fails to build:

class A(Executor):
    @handler
    async def go(self, x: str, ctx: WorkflowContext[list[str]]): ...

class B(Executor):
    @handler
    async def take(self, items: list, ctx: WorkflowContext[None, list]): ...

WorkflowBuilder(start_executor=a).add_edge(a, b).build()
# TypeCompatibilityError: ... outputs ['list[str]'] but target ... can only handle [<class 'list'>]

is_type_compatible compares get_origin(list[str]) (list) with get_origin(list) (None) in Case 5 and returns False before the "one side is untyped, assume compatible" rule in Case 6 is reached. The runtime check already accepts the message. The reverse, list -> list[str], fails the same way.

Description & Review Guide

• What are the major changes? When one side is a bare container class, compare it with the other side's container with issubclass. list[str] -> list, dict[str, int] -> dict, list[int] -> Sequence and list -> list[str] are now compatible; list[str] -> dict still isn't.
• What is the impact of these changes? Workflows with an unparameterized container input build instead of raising.
• What do you want reviewers to focus on? list[Message] -> Sequence[Message] (both parameterized, different containers) is still rejected by Case 5. I left that out to keep this small.

Related Issue

No existing issue.

Contribution Checklist

• The code builds clean without any errors or warnings
• All unit tests pass, and I have added new tests where possible

Tests: a unit case in test_typing_utils.py and a workflow build in test_validation.py; both fail on main. pytest packages/core/tests/workflow passes, and ruff and the repo's pre-commit checks are clean.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Eduard van Valkenburg (eavanvalkenburg)]

Anish Mehta (@anishmehta24) This still rejects bare aliases from typing, such as list[str] -> typing.Sequence: typing.Sequence has an origin and no type arguments, so neither new bare-container branch matches and the different-container check rejects it. Please treat origin-with-empty-args aliases as bare containers and add a regression for this case.

[Anish Mehta (anishmehta24)]

Updated so a bare typing alias with no type args, like typing.Sequence or typing.List, gets treated as the plain container it stands for before the checks run. I added list[str] -> typing.Sequence and a few other typing alias cases to the regression test.