Equivalence between similar-looking types

[gvanrossum]

Lukasz asks a series of questions about type equivalence.

• Set is not Set[Employee]. Correct!
• Set != Set[Employee]. (He didn't ask this, but I'm inserting it in the list because it's a useful question to ask.) Correct again.
• Set is Set[Any]. No. I'm tempted to make these different objects, even if they have the same meaning, just so that we can have G[t1][t2] == G[t1, t2] for any generic type taking two arguments. For example a dict with string keys but unspecified values could be written as Dict[str] or Dict[str, Any], but only the first form could be further parametrized with a value type, so Dict[str][int] is equivalent to Dict[str, int].
• Set == Set[Any]. Again, no, since these behave differently.
• Set[Employee] is Set[Employee]. I think not. Given that the is operator means object identity, this would require some kind of caching of all parametrized type objects, and I'd like to avoid that.
• Set[Employee] == Set[employee]. Yes. (The cat should be out of the bag by now. I am proposing an eq method on generic type objects to make this true.)
• issubclass(Set[Employee], Set). Hm... This reeks of the covariance/contravariance discussion (issue Covariance or contravariance #2). But for the special case of a parametrizable type and a parametrized version of that type I think this is reasonable.
• issubclass(Set[Manager], Set[Employee]). See issue Covariance or contravariance #2.

[ambv]

What does it mean that Set != Set[Any]?

I would also like if Dict[str] was invalid (type checker error) and Dict[str, Any] or Dict[str, ConcreteType] was mandatory. One obvious way to do it. Especially that we overload [] quite a lot in this proposal, with Unions, Callables and Tuples further complicating the issue.

[gvanrossum]

Set != Set[Any] because Set[Any] cannot be further parametrized (Any is not a type variable) while Set can be.

Also, even if we decide that subclassing is invariant so Set[Manager] is not a subclass of Set[Employee](nor vice versa), I would still like to be able to see both being a subclass of (unparametrized) Set.

Agreed that Dict[str] should be illegal (and it is, both in mypy and in my prototype).

[ambv]

OK, will update the PEP accordingly.

[gvanrossum]

I don't think there's anything left to do here. Closing.