[ty] implement disjointness of Callable vs SpecialForm

[carljm]

Summary

Fixes astral-sh/ty#557

Test Plan

Stable property tests succeed with a million iterations. Added mdtests.

[AlexWaygood]

This special form is callable:

ruff/crates/ty_python_semantic/src/types/special_form.rs

Line 102 in 1274521

TypedDict,

[github-actions]

mypy_primer results

No ecosystem changes detected ✅

[carljm]

@AlexWaygood It looks like ChainMap, DefaultDict, Counter, Deque, and OrderedDict (the collections proxies) are callable at runtime, but in typeshed are annotated as _Alias, which has no __call__. Do you think we should model their runtime callability as a special case, or trust typeshed here?

[AlexWaygood]

The collections proxies are callable, but the builtins proxies aren't?! That's... Odd. I had in my head that all the legacy stdlib aliases were not callable!

We should probably treat them as callable if they are at runtime — can we just delegate to the constructor signatures of the classes they're aliasing? I don't love the idea of hardcoding their constructors' signatures somewhere in our model — some of those classes have reasonably complicated constructor methods IIRC

[carljm]

can we just delegate to the constructor signatures of the classes they're aliasing

Yeah, that should be possible. It's beyond the scope of what I was looking to do in this PR, but I added a TODO for it.

[carljm]

can we just delegate to the constructor signatures of the classes they're aliasing

In that case, is there any reason not to just treat them as direct aliases? That is, remove their SpecialForm type entirely and act as if typing.pyi imported them directly from collections?

[AlexWaygood]

PEP 585 states:

Importing [the legacy aliases] from typing is deprecated. Due to PEP 563 and the intention to minimize the runtime impact of typing, this deprecation will not generate DeprecationWarnings. Instead, type checkers may warn about such deprecated usage when the target version of the checked program is signalled to be Python 3.9 or newer. It’s recommended to allow for those warnings to be silenced on a project-wide basis.

I think pyright implements this deprecation, and it would be nice if we could eventually as well. If we didn't distinguish between typing.ChainMap and collections.ChainMap at all in our model, that might be tricky?

Edit: Hmm, come to think of it, though, we'll have the same "tricky" issue when it comes to implementing deprecation warnings for typing.Iterator, typing.Iterable, typing.Mapping, etc. According to typeshed, these aren't just aliases for stdlib classes in collections.abc -- according to typeshed, these are actually defined in typing (and re-exported in collections.abc). There have been numerous attempts to move the class definitions to the collections.abc stub, but it's tough because existing type checkers hardcode assumptions that these class definitions will be found in typing.

Given that we'll maybe have to solve that issue for the collections.abc aliases anyway, maybe it doesn't actually help us at all to represent typing.ChainMap as a different type internally to collections.ChainMap.

[AlexWaygood]

The collections proxies are callable, but the builtins proxies aren't?! That's... Odd. I had in my head that all the legacy stdlib aliases were not callable!

It looks like the builtin aliases are specifically excluded from being callable at runtime by passing the inst=False keyword argument: https://github.com/python/cpython/blob/24069fbca861a5904ee7718469919e84828f22e7/Lib/typing.py#L2701-L2785. Why the decision was made to treat these aliases differently to other stdlib aliases, I'm not sure.