TypeVar equality broken?

[pitrou]

This looks unexpected to me:

>>> import typing
>>> typing.TypeVar('T') == typing.TypeVar('T')
False
>>> 

[ilevkivskyi]

FWIW this is actually intentional. I think it was discussed briefly on this tracker, the main motivation is that from the point of view of static type checkers two type variables even with the same name can be different, they follow special scoping rules specified by PEP 484, for example:

T = TypeVar('T')

def f(x: T) -> T: ... # the two T's here are the same
def g(x: T) -> T: ... # the two T's here are the same, but different from the two T's above 

Also this is how type variables work in some other statically typed languages with generics/templates/etc. They get (re-)bound by a class or function definition.

I however don't have any strong opinion on their runtime behavior. @gvanrossum may add to this.

[gvanrossum]

Why would you ever want to compare TypeVars?

[pitrou]

This occurred during unit testing.

[pitrou]

Sorry, a bit more context: I was trying to add serialization support for typing hints in cloudpickle (see issue #511), and tried to use assertEqual to compare the original type and the unpickled result.

[gvanrossum]

Hm, I'd expect a TypeVar to be pickled as a reference, not as a value (just like references to classes and functions). Though for that to work we'd need to add __module__ to TypeVars.

[ilevkivskyi]

Hm, I'd expect a TypeVar to be pickled as a reference, not as a value (just like references to classes and functions). Though for that to work we'd need to add __module__ to TypeVars.

If we all agree that type variables should be treated as "immutable", i.e. copy(T) is T and loads(dumps(T)) is T then I can make a PR for this.

[gvanrossum]

There is no API to mutate a TypeVar and IMO there shouldn't be -- conceptually it really is just a token. So I agree. Hopefully this is acceptable to Antoine?

[pitrou]

Yes, it sounds ok.