Two question:
- PEP586 stated that
typing.Tuple[1,2,3]is not possible because that crashes with python 3.7, but it seems it no longer does since 3.11, so is that rationale for rejecting bare literals even still applicable? The only thing that causes issues are unions, no? - Are there any more concrete examples for this proposal rather than just unions of int / string literals?
Because if all we want to fix is verboseness of something like error_level: Literal[1, 2, 3], I think there are simpler alternatives:
- introduce something like
typing.{IntEnum, StrEnum}that, other than regular enums, really is compatible with the literal values. (Amend PEP 586 to make `enum` values subtypes of `Literal` - #11 by randolf-scholz) - or allow something like
error_level: {1,2,3}with a set literal as a substitute for the union.
Your motivation section mentions checking array sizes. I imagine you may wish to do something like
def concat[n: int, m: int](left: Vec[n], right: Vec[m]) -> Vec[n + m]: ...
with the goal that a type checker would be able to do the arithmetic when checking something like concat(vec3, vec5) ? By translating the + on the type-vars into a + on the upper bounds / solved values of the type-vars ? But wouldn’t this run into problems of ill-posedness, for instance if we have something like n | m it would no longer be clear if this is now the union of the type-vars or the OR-operator on the solved types.
You also mention inline typed dicts, but again there are no concrete examples in the motivation section. I think it would really help a lot if you could add one or two demos per use case on how they would benefit from your proposal.