fixup! specify that parameter specification should have variance

fixup! fixup! specify that parameter specification should have variance

Author: KotlinIsland

conformance/tests/generics_paramspec_variance.py

@@ -7,6 +7,14 @@
 
 from typing import Callable, Generic, ParamSpec
 
+
+class InvariantParamSpec[**InOutP]:
+    a: Callable[InOutP, None]
+
+in_out_obj: InvariantParamSpec[object] = InvariantParamSpec[int]()  # E
+in_out_int: InvariantParamSpec[int] = InvariantParamSpec[object]()  # E
+
+
 class ContravariantParamSpec[**InP]:
     def f(self, *args: InP.args, **kwargs: InP.kwargs): ...
 

conformance/tests/generics_typevartuple_variance.py

@@ -7,11 +7,19 @@
 
 from typing import Generic, TypeVarTuple
 
+class InvariantTypeVarTuple[*InOutTs]:
+    a: tuple[*InOutTs]
+
+in_out_obj: InvariantTypeVarTuple[object] = InvariantTypeVarTuple[int]()  # E
+in_out_int: InvariantTypeVarTuple[int] = InvariantTypeVarTuple[object]()  # E
+in_out_int = InvariantTypeVarTuple[int]()  # E
+
+
 class ContravariantTypeVarTuple[*InTs]:
     def f(self, t: tuple[*InTs]):
         raise NotImplementedError
 
-in_obj: ContravariantTypeVarTuple[object] = ContravariantTypeVarTuple[int]()  # E
+in_obj: ContravariantTypeVarTuple[object, object] = ContravariantTypeVarTuple[int]()  # E
 in_int: ContravariantTypeVarTuple[int] = ContravariantTypeVarTuple[object]()  # OK
 
 
@@ -22,6 +30,10 @@ def f(self) -> tuple[*OutTs]:
 
 out_int: CovariantTypeVarTuple[int] = CovariantTypeVarTuple[object]()  # E
 out_obj: CovariantTypeVarTuple[object] = CovariantTypeVarTuple[int]()  # OK
+out_multiple: CovariantTypeVarTuple[float, float] = CovariantTypeVarTuple[
+    int,  # OK
+    object,  # E
+]()
 
 
 InTs = TypeVarTuple("InTs", contravariant=True)

docs/spec/generics.rst

@@ -678,8 +678,9 @@ Prior to 3.12, the ``ParamSpec`` constructor can be used.
    P = ParamSpec("WrongName") # Rejected because P =/= WrongName
 
 The runtime should accept ``bound``\ s and ``covariant`` and ``contravariant``
-arguments in the declaration just as ``typing.TypeVar`` does, but for ``bound`` we
-will defer the standardization of the semantics of this option to a later PEP.
+arguments in the declaration just as ``typing.TypeVar`` does.
+
+We defer the standardization of the semantics of the ``bound`` option to a later PEP.
 
 .. _`paramspec_valid_use_locations`:
 
@@ -2712,8 +2713,8 @@ The algorithm for computing the variance of a type parameter is as follows.
 For each type parameter in a generic class:
 
 1. If the type parameter comes from a traditional
-``TypeVar``/``TypeVarTuple``/``ParamSpec`` declaration and is not specified
-as ``infer_variance`` (see below), its variance is specified by the
+``TypeVar``/``TypeVarTuple``/``ParamSpec`` declaration and is not constructed
+with ``infer_variance=True`` (see below), its variance is specified by the
 constructor call. No further inference is needed.
 
 2. Create two specialized versions of the class. We'll refer to these as
@@ -2725,7 +2726,8 @@ specialize the target type parameter with:
 
  an ``object`` instance for a type variable.
  a ``*tuple[object, ...]`` value for a type variable tuple.
- a ``...`` value for a parameter specification.
+ a for a parameter specification, a 'top signature' value, i.e. a type
+ that represents the super type of every possible signature.
 
 This specialization ignores the type parameter's upper bound or constraints.
 In the ``lower`` specialized class, specialize the target type parameter with