Skip to content

Improve how to get different types of Dispatch.target #139

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
llucax opened this issue Mar 27, 2025 · 0 comments · May be fixed by #168
Open

Improve how to get different types of Dispatch.target #139

llucax opened this issue Mar 27, 2025 · 0 comments · May be fixed by #168
Assignees
Labels
part:client Affects the client code priority:high Address this as soon as possible scope:breaking-change Breaking change, users will need to update their code type:enhancement New feature or enhancement visitble to users

Comments

@llucax
Copy link
Contributor

llucax commented Mar 27, 2025

What's needed?

It is difficult to use the current targets, defined as TargetComponents = list[int] | list[ComponentCategory], because the match statement (and isinstance() can't deal with containers, so we can check that something is a list but not that is a list[int]. We had issues in the past getting this right and we still do.

Proposed solution

Use wrapper classes, and then the match syntax should work (I think, untested):

class TargetIds(list[int]): pass
class TargetCategories(list[ComponentCategory]): pass
TargetComponents: TypeAlias = TargetIds | TargetCategories

match components:
    case TargetIds() as component_ids:
        print("components to %s", component_ids)
    case TargetCategories() as categories:
        print("components to %s", categories)
    case unsupported:
        assert_never(unsupported)

While we are it, maybe we can even change this to use frozenset instead of list to make it clear there should be no duplicates.

Use cases

No response

Alternatives and workarounds

Another option could be to make TargetComponents a class and have methods to check which (ids or categories) are really present, but I think it will be more implementation boileplate, and a unsafer usage (as it would be hard to get exhaustion checks in case more ways to specify targets are added in the future).

Additional context

No response

@llucax llucax added part:client Affects the client code priority:high Address this as soon as possible scope:breaking-change Breaking change, users will need to update their code type:enhancement New feature or enhancement visitble to users labels Mar 27, 2025
@Marenz Marenz self-assigned this May 19, 2025
@Marenz Marenz linked a pull request May 19, 2025 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
part:client Affects the client code priority:high Address this as soon as possible scope:breaking-change Breaking change, users will need to update their code type:enhancement New feature or enhancement visitble to users
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants