Spec: More precision on type parameter order
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 1.8k
- Forks
- 302
- Avg merge
- 23h
- Merged PRs (30d)
- 8
Description
The spec currently isn't very precise on the order in which type parameters appear in a class. (Given a class C that is generic over type parameters T1 and T2, does C[int, str] mean that T1 is bound to int or that T2 is bound to int?)
I think the rule should be:
- If PEP 695 syntax is used, the order is the order in which the type parameters appear in the type parameter list.
- If the class has
Generic[...]as a syntactic base, the order is the order of the type arguments toGeneric. - If the class has
Protocol[...]as a syntactic base, the order is the order of the type arguments toProtocol. This applies only if Protocol is subscripted, not if the class inherits from bareProtocol. - Otherwise, the order is the order in which the type parameters appear syntactically in the base class list.
As far as I know, this is how all type checkers currently behave, but we just found out it's not how the runtime behaves when Protocol is involved: https://github.com/python/cpython/issues/137191#issuecomment-3132748382.
In these examples, all classes are generic over two parameters T1 and T2, and in all cases the type parameter order is T1, T2:
from typing import Generic, Protocol, TypeVar
class C1[T1, T2]: ... # order is T1, T2
T1 = TypeVar("T1")
T2 = TypeVar("T2")
class C2(C1[T2, T1], Generic[T1, T2]): ... # order is T1, T2
class GenericProto[T1, T2](Protocol): ... # order is T1, T2
class Proto2(GenericProto[T2, T1], Protocol[T1, T2]): ... # order is T1, T2
class Proto3(GenericProto[T1, T2], Protocol): ... # order is T1, T2
class C3(C2[T1, T2]): ... # order is T1, T2
We should change the spec to make this rule explicit. The only current rule appears to be in https://typing.python.org/en/latest/spec/generics.html#arbitrary-generic-types-as-base-classes "Type variables are applied to the defined class in the order in which they first appear in any generic base classes".
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the “Arbitrary generic types as base classes” section of the generics specification, especially its current type-variable ordering rule. Compare that wording with the proposed PEP 695, Generic, Protocol, and base-class cases in the issue. Done means the specification explicitly defines the ordering for each case and matches the examples given.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 55/100