Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TypeAliasType with should also raise an error if non-default type parameter follows default type parameter #124787

Open
Daraan opened this issue Sep 30, 2024 · 7 comments
Labels
topic-typing type-bug An unexpected behavior, bug, or error

Comments

@Daraan
Copy link

Daraan commented Sep 30, 2024

Bug report

Bug description:

The following statement is invalid:

type X[T_default=int, T] = (T_default, U) 
# SyntaxError: non-default type parameter 'T' follows default type parameter

However, writing it as a TypeAliasType is possible. The following should likely raise an error as well to mimic this behavior:

from typing import TypeAliasType, TypeVar
T = TypeVar('T')
T_default = TypeVar("T_default", default=int)
TypeAliasType("TupleT_default_reversed", tuple[T_default, T], type_params=(T_default, T))
print("OK")

CPython versions tested on:

3.13

Operating systems tested on:

Linux

Linked PRs

@Daraan Daraan added the type-bug An unexpected behavior, bug, or error label Sep 30, 2024
@Daraan Daraan changed the title TypeAliasType with wrong default order should raise an error. TypeAliasType with should also raise an error if non-default type parameter follows default type parameter Sep 30, 2024
Daraan added a commit to Daraan/typing_extensions that referenced this issue Sep 30, 2024
@sobolevn
Copy link
Member

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.

@JelleZijlstra
Copy link
Member

_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.

@sobolevn
Copy link
Member

There's one more problem that I've noticed. This is allowed: TypeAliasType('a', int, type_params=(1, 2))

Was allowed :)

@Daraan
Copy link
Author

Daraan commented Sep 30, 2024

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

@Daraan
Copy link
Author

Daraan commented Sep 30, 2024

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?

@JelleZijlstra
Copy link
Member

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.

sobolevn added a commit that referenced this issue Oct 11, 2024
@Daraan
Copy link
Author

Daraan commented Nov 25, 2024

Should this stay open or can we close it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic-typing type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

No branches or pull requests

3 participants