KEMBAR78
Support `TypeAliasType` explicit call by sobolevn · Pull Request #16644 · python/mypy · GitHub
Skip to content

Conversation

@sobolevn
Copy link
Member

The implementation turned out to be quite simple for the common cases.
Note: Right now there's no check that type_params= is correct, I am not sure that this is even required for a type-checker (in any case, this can and should be done in a follow-up PR)

Refs #16614

@github-actions

This comment has been minimized.

@sobolevn
Copy link
Member Author

I will try to find how to fix typevar representation change without code modifications, I think that this has to do with my typing fixtures.

@github-actions
Copy link
Contributor

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

@tmke8
Copy link
Contributor

tmke8 commented Dec 11, 2023

One big advantage of X = TypeAliasType("X", ...) over X: TypeAlias = ... is that you can choose the order of the type parameters:

from typing import TypeVar
from typing_extensions import TypeAliasType

K = TypeVar("K")
V = TypeVar("V")

InvertedDict = TypeAliasType("InvertedDict", dict[K, V], type_params=(V, K))

def f(x: InvertedDict[int, str]) -> None:
    reveal_type(x)

pyright correctly reveals the type as dict[str, int] (i.e., inverted), but this branch reveals:

main.py:10: note: Revealed type is "builtins.dict[builtins.int, builtins.str]"

@JelleZijlstra
Copy link
Member

I don't think we should claim support for TypeAliasType without checking the type_params. Explicit type_params are the main differentiating factor that sets the new syntax apart.

Copy link
Collaborator

@hauntsaninja hauntsaninja left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd be fine with this PR if we issue an error if type_params is provided

Also thanks for good detail spot tmke8!

@hamdanal
Copy link
Collaborator

Hello @sobolevn, I'd like to try and finish up this PR if that's OK with you.

@sobolevn
Copy link
Member Author

@hamdanal please, go ahead :)
I forgot about it, sorry.

@hamdanal hamdanal mentioned this pull request Feb 17, 2024
JelleZijlstra pushed a commit that referenced this pull request Mar 11, 2024
Builds on top of and supersedes #16644

---------

Co-authored-by: sobolevn <mail@sobolevn.me>
@JelleZijlstra
Copy link
Member

Merged #16926 instead, thanks for your work here!

@JelleZijlstra JelleZijlstra deleted the issue-16614 branch March 11, 2024 14:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants