Is it feasible to check for redundant type unions?

[Avasam]

Inspired by flake8-pyi's Y041 (redundant numeric unions), Y051 (redundant unions between Literal types and builtin supertypes), PyCQA/flake8-pyi#283 (comment) and typescript-eslint's no-redundant-type-constituents. Is it possible to check if a type union is redundant? I expect this could get really complex, especially with type alias and protocols. So maybe just checking if a type inherits from another to start with.
A few examples: int | float, object | None, ChildClass | ParentClass, str | Sequence[str]

Unions with Any should probably be ignored as it's an escape hatch and can still be used to partially express an expected type.

[erictraut]

From a type analysis perspective, there's nothing wrong with unions that contain mutual subtypes, so that in itself is not a bug.

Unions are created in may ways during type evaluation. The examples you've listed above involve the most straightforward way involving a Union or | expression with explicit "atomic" types. It's also possible to include type aliases within a union expression. And unions get created for hundreds of different reasons during type evaluation (e.g. through type narrowing or type inference).

There are two questions that I think we need to answer here.

1. Do redundant type unions underlie a common source of actual bugs or code fragility? My sense is that they don't. With the possible exception of str | Sequence[str], I can't think of any real-world problems that I've encountered.
2. If we were to implement such a check, under what circumstances would it apply? Only for explicit Union or | expressions? What if those expressions involved type aliases? Would Any be exempt if included in an explicit union?

[Avasam]

From a type analysis perspective, there's nothing wrong with unions that contain mutual subtypes, so that in itself is not a bug.

Agreed, just trying to see which checker could, and is willing, to implement such check. A type-checker (like pyright) seems appropriate.

1. Redundant type unions can underline a misunderstanding of the type system. Especially for a user coming from a different system (like TypeScript)
2. Checking for aliases would be nice, as it'd catch cases when an alias is already included in another alias. But I wouldn't necessary ask for a check with complex recursive type checking or whatnot. Simple Unions are mainly be what I'm going for. Any would be exempt.

[srittau]

I could see a flat redundancy check be useful. E.g., marking int | float, int | str | int, or Sub | Super. (But even then I'd prefer to use datetime | date over just date.) Deep redundancy checks could be quite annoying, though. E.g., Foo | Bar or even Foo | int, where Foo and Bar are type aliases to either int or a union containing int. But flat checks could probably be implemented in a linter, except for the sub-class case. (And harcoding a few basic types like int/float.)