Open Daraan opened 1 month ago
I would like to work on this, if no one else has already started. We need to check both Python API and our internal _Py_make_typealias
C-API. I think that raising TypeError
here is appropriate for the invalid input.
_Py_make_typealias
is only used for creating type aliases from the type
statement in the interpreter. Because we already validate ordering in the parser, we don't strictly need to validate again in that case.
There's one more problem that I've noticed. This is allowed: TypeAliasType('a', int, type_params=(1, 2))
Was allowed :)
There's one more problem that I've noticed. This is allowed:
TypeAliasType('a', int, type_params=(1, 2))
Was allowed :)
👀
I have the suspicion that everything(?) can be passed as long as it is packed in a tuple. One could argue that this is a job for type-checkers to detect. But, where does one draw the line 😅? I have no opinion here btw.
I found another case that is invalid, a repeated type parameter, see https://peps.python.org/pep-0695/#specification.
type A[T, T] = ... # SyntaxError
type B[T, *T] = ... # SyntaxError
type C[T, **T] = ... # SyntaxError
A question PEP 696 states
The compiler would enforce [...] that TypeVars with defaults cannot immediately follow TypeVarTuples.
class G[*Ts, T=int]: ...
TypeError: Type parameter with a default follows TypeVarTuple
but
type Foo[*Ts, T=int] = tuple[*Ts] | list[T]
is okay.
Is this an oversight, or an exception?
That's a runtime error, not a compile-time error. I think it's fine for the type statement (as well as generic functions) to be a bit more permissive at runtime here.
Bug report
Bug description:
The following statement is invalid:
However, writing it as a
TypeAliasType
is possible. The following should likely raise an error as well to mimic this behavior:CPython versions tested on:
3.13
Operating systems tested on:
Linux
Linked PRs