Check for redundant object unions

[Avasam]

I'd like a check similar to Y041, but for unions with object. Especially for object | None, coming from a Typescript background, it is not obvious to me that this type union is redundant, and I often make that mistake (or forget about it and leave it in a stub).

[AlexWaygood]

Hmm, I'm not sure.

Y041 and Y051 both essentially deal with special cases; since we're not a type checker, there's no easy, generalised way for us to answer the question "Is X a subtype of Y?". So the question is -- is this problem common enough to be worth adding another special case that we check for here? And I don't feel like I've seen this problem come up much in typeshed.

@twoertwein, have you seen this problem come up much in pandas-stubs at all?

[twoertwein]

@twoertwein, have you seen this problem come up much in pandas-stubs at all?

Not with object but often with Hashable. Could maybe have a rule with all built-in hashable objects (slice, tuple, ...) that occur in a Union with Hashable?

edit: and something like str | Sequence[str] string is a Sequence of strings :)

[AlexWaygood]

Could maybe have a rule with all built-in hashable objects (slice, tuple, ...) that occur in a Union with Hashable?

Hashable is kind of problematic as a type :\\\

See, e.g., the comment in typeshed. Personally, I'd be quite hesitant to ever use Hashable as an annotation, so I'm not sure I'd want to write a lint rule encouraging it. Mypy has a pretty poor understanding of hashability currently (e.g. it hilariously thinks all unhashable classes break LSP).

And to be fair to mypy, hashability does break all kinds of OOP norms in Python. Consider the following code. Is Y a subtype of Hashable or not?

from typing import Hashable

class X(Hashable):
    def __hash__(self) -> int:
        return 42

class Y(X):
    __hash__ = None

[AlexWaygood]

something like str | Sequence[str] string is a Sequence of strings :)

Strictly speaking that's redundant, but you might often want that for documentation purposes :)

[twoertwein]

Hashable is kind of problematic as a type :\\

good to know - pandas(-stubs) use it quite extensively. I assume the same applies to object: it is also Hashable - a list "obviously" cannot possibly inherit from object because it is not Hashable :)

[AlexWaygood]

I assume the same applies to object: it is also Hashable - a list "obviously" cannot possibly inherit from object because it is not Hashable :)

Yup! It's type: ignored in typeshed to make mypy happy, just like all the other unhashable classes... https://github.com/python/typeshed/blob/c9346f32e10fc631e691745e2a8c24bc3216642f/stdlib/builtins.pyi#L991

[AlexWaygood]

There was an attempt a while back to make the dict KeyType TypeVar bound to Hashable, but it would have broken half the typed-Python ecosystem: python/typeshed#6244

[AlexWaygood]

I'm closing this issue for now, but I'm happy to reopen if I see more evidence that this is a widespread issue :)

[AlexWaygood]

This recently came up again in python/typeshed#8801 (comment)

[AlexWaygood]

Hmm, looks like pandas-stubs did just hit this: https://github.com/pandas-dev/pandas-stubs/pull/341/files#diff-405f1fc50a0e07eb9cb39aa6a78c0e80e63d3078deb0f8fc1081605913715688R56

[JelleZijlstra]

Though that's because of a mypy bug (python/mypy#13760).

[Avasam]

Relevant pyright discussion: microsoft/pyright#3949