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

Optimize Unpack for failures #15967

Merged
merged 2 commits into from
Aug 29, 2023

Conversation

ilevkivskyi
Copy link
Member

This is a small but possibly important PR. Wherever possible we should represent user error and/or failed type inference as *tuple[Any, ...]/*tuple[<nothing>, ...], rather than Unpack[Any]/Unpack[<nothing>] or plain Any/<nothing>. This way we will not need any special casing for failure conditions in various places without risking a crash instead of a graceful failure (error message).

@ilevkivskyi ilevkivskyi requested review from jhance and JukkaL August 26, 2023 10:48
@github-actions

This comment has been minimized.

@github-actions
Copy link
Contributor

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

@ilevkivskyi ilevkivskyi merged commit 1714028 into python:master Aug 29, 2023
@ilevkivskyi ilevkivskyi deleted the optimize-unpack-failures branch August 29, 2023 09:17
JukkaL pushed a commit that referenced this pull request Oct 10, 2023
This is a small but possibly important PR. Wherever possible we should
represent user error and/or failed type inference as `*tuple[Any,
...]`/`*tuple[<nothing>, ...]`, rather than
`Unpack[Any]`/`Unpack[<nothing>]` or plain `Any`/`<nothing>`. This way
we will not need any special casing for failure conditions in various
places without risking a crash instead of a graceful failure (error
message).
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.

1 participant