parameter specification/type variable tuple variance

[KotlinIsland]

discussion: https://discuss.python.org/t/parameter-specifications-should-have-variance/106452

• support in basedpyright variance for parameter specification and type variable tuples DetachHead/basedpyright#1771
• support in pycharm: JetBrains/intellij-community@7196a70
• cpython tvt variance: gh-148207: add additional keywords to typing.TypeVarTuple cpython#148212
• typeshed: typing.TypeVarTuple: add bound/variance properties from 3.15 typeshed#15670
• typing_extensions: Type variable tuple variance typing_extensions#741
• typing-council: spec change: support variance on parameter specification and type variable tuple typing-council#59

[JelleZijlstra]

I like adding this if we can get it specified nicely, but this PR is not ready; the proposed test is incorrect.

Also, https://typing.python.org/en/latest/spec/generics.html#paramspec-variables still says variance on ParamSpec is unsupported; this should be updated.

I'd also like to see an implementation in at least one type checker, even if only as a draft PR, so we can be confident this is something that can be feasibly implemented.

[davidhalter]

I personally would also like to see tests added for param spec variance inference, since that would probably need to be supported as well.

[JelleZijlstra]

The test cases do have variance inference, though as I noted some of the cases are wrong. But it would probably be useful to have a few more cases, and I'd recommend putting the tests for paramspec variance in their own file so we can track type checker support more precisely.

[KotlinIsland]

I'd also like to see an implementation in at least one type checker

I have wip support in PyCharm, but I could also add it to basedpyright

it was very straightforward to implement

[davidhalter]

The test cases do have variance inference, though as I noted some of the cases are wrong. But it would probably be useful to have a few more cases, and I'd recommend putting the tests for paramspec variance in their own file so we can track type checker support more precisely.

Oh right, sorry I didn't see them, because I thought they would be in a different file. I'm also very much +1 on putting those tests into a different file (for example generics_paramspec_variance.py).

[KotlinIsland]

support has landed in pycharm and cpython

[JelleZijlstra]

https://typing.python.org/en/latest/spec/generics.html#paramspec-variables stills says that we don't support variance in ParamSpec, that should be fixed in this PR.

[JelleZijlstra]

Also can you open an issue on python/typing-council asking for a formal pronouncement?

[KotlinIsland]

python/typing-council#59

[JelleZijlstra]

Noticed some more issues:

• generics_typevartuple_basic.py still has a line Ts1 = TypeVarTuple("Ts1", covariant=True) # E. But of course that's legal now. I'd delete the line and leave all variance testing to the new file generics_typevartuple_variance.py.
• The description of the variance inference algorithm says "In the upper specialized class, specialize the target type parameter with an object instance". But that doesn't make sense for ParamSpec and TypeVarTuple. I think TypeVarTuple should instead be specialized with *tuple[object, ...]. For ParamSpec perhaps Callable[..., object] is right but not 100% sure.
• The way the tests are written produces some incidental errors, like from ty generics_paramspec_variance.py:28:23: error[empty-body] Function always implicitly returns `None`, which is not assignable to return type `(...) -> Unknown` and mypy generics_typevartuple_variance.py:18: error: Missing return statement [empty-body]. Should add something like raise NotImplementedError.

[KotlinIsland]

Callable[..., object] is right but not 100% sure.

not Callable, and not ..., as this is the gradual form. but (*object, **object), which is a non-denotable psuedo representation of the widest value for a parameter specification

[JelleZijlstra]

I don't think that's right. The form we want here should be a supertype of every other possible value, and something like a one-parameter callable is not a subtype of (*: object, **: object).

[AlexWaygood]

In ty we have a type that we spell as Top[Callable[..., object]] in ty's type display (a fully static type describing the infinite union of all possible Callable types). It's not representable using standard Python notation currently.

[JelleZijlstra]

We only need assignability not subtyping here, so I think ... is enough.

[carljm]

Thanks! Definitely support this change.

[carljm]

I don't think using ... here is sound. Because it is both assignable-to and assignable-from any paramspec, it means that a case like the ContravariantParamSpec test will wrongly infer the paramspec as covariant (because lower is assignable to upper) before it even checks the contravariant direction.

I don't think there is any way to make the variance-inference algorithm described here correct and support inference of ParamSpec variance, without introducing the new concept of a "top signature".

(I'm also not sure how much value there is in including this particular variance-inference algorithm in the spec. I think it describes pyright's algorithm. I know that ty and pyrefly do not use this algorithm. I don't know about mypy or zuban.)

[KotlinIsland]

(I'm also not sure how much value there is in including this particular variance-inference algorithm in the spec. I think it describes pyright's algorithm. I know that ty and pyrefly do not use this algorithm. I don't know about mypy or zuban.)

i agree, but i think this point is out of the scope of this change

[JelleZijlstra]

We need to describe the algorithm somehow, don't we? Other type checkers use a different algorithm in practice, but to be conformant they need to follow an algorithm that has the same results as that described in the spec.

[carljm]

Depending on the situation I think it can be fine (or preferable) for the spec to describe the required results without specifying a particular algorithm to reach them. In this case I'm not sure that would be any simpler (and in any case I don't think we should remove this algorithm in this PR.)

I think for this PR we can fairly simply describe the nature of the top signature (the union of all possible callable signatures) without having to go too deep into it.

[carljm]

Here too, I think we should have tests for invariant TypeVarTuple.

[carljm]

We only need assignability not subtyping here, so I think ... is enough.

But we also need assignability to fail in the "wrong" direction, and this workaround fails that requirement.

[KotlinIsland]

i've pushed changes, it's good to review again