Using typing_extension.Unpack results in INTERNAL ERROR
#13981
Labels
Comments
AlexWaygood
added
crash
topic-pep-646
|
cc @jhance FYI |
|
Similarly: |
ilevkivskyi
added a commit
that referenced
this issue
Aug 23, 2023
Fixes #13981 Fixes #15241 Fixes #15495 Fixes #15633 Fixes #15667 Fixes #15897 Fixes #15929 OK, I started following the plan outlined in #15879. In this PR I focused mostly on "kinematics". Here are some notes (in random order): * I decided to normalize `TupleType` and `Instance` items in `semanal_typeargs.py` (not in the type constructors, like for unions). It looks like a simpler way to normalize for now. After this, we can rely on the fact that only non-trivial (more below on what is trivial) variadic items in a type list is either `*Ts` or `*tuple[X, ...]`. A single top-level `TupleType` can appear in an unpack only as type of `*args`. * Callables turned out to be tricky. There is certain tight coupling between `FuncDef.type` and `FuncDef.arguments` that makes it hard to normalize prefix to be expressed as individual arguments _at definition_. I faced exactly the same problem when I implemented `**` unpacking for TypedDicts. So we have two choices: either handle prefixes everywhere, or use normalization helper in relevant code. I propose to go with the latter (it worked well for `**` unpacking). * I decided to switch `Unpack` to be disallowed by default in `typeanal.py`, only very specific potions are allowed now. Although this required plumbing `allow_unpack` all the way from `semanal.py`, conceptually it is simple. This is similar to how `ParamSpec` is handled. * This PR fixes all currently open crash issues (some intentionally, some accidentally) plus a bunch of TODOs I found in the tests (but not all). * I decided to simplify `TypeAliasExpr` (and made it simple reference to the `SymbolNode`, like e.g. `TypedDictExpr` and `NamedTupleExpr`). This is not strictly necessary for this PR, but it makes some parts of it a bit simpler, and I wanted to do it for long time. Here is a more detailed plan of what I am leaving for future PRs (in rough order of priority): * Close non-crash open issues (it looks like there are only three, and all seem to be straightforward) * Handle trivial items in `UnpackType` gracefully. These are `<nothing>` and `Any` (and also potentially `object`). They can appear e.g. after a user error. Currently they can cause assert crashes. (Not sure what is the best way to do this). * Go over current places where `Unpack` is handled, and verify both possible variadic items are handled. * Audit variadic `Instance` constrains and subtyping (the latter is probably OK, but the former may be broken). * Audit `Callable` and `Tuple` subtyping for variadic-related edge cases (constraints seem OK for these). * Figure out story about `map_instance_to_supertype()` (if no changes are needed, add tests for subclassing). * Clear most remaining TODOs. * Go once more over the large scale picture and check whether we have some important parts missing (or unhandled interactions between those). * Verify various "advanced" typing features work well with `TypeVarTuple`s (and add some support if missing but looks important). * Enable this feature by default. I hope to finish these in next few weeks.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug Report
I'm trying to use
typing_extensions.Unpackin python 3.7.11 to check the annotation of a higher order function. The function with annotation looks like this:I first used the latest published version of mypy (0.982) to do the type checking. this lead to this error:
Running with the suggested flag
--enable-incomplete-featuresproduced another error:So I installed mypy from source. The build version is: 1.0.0+dev.55d0adf17a15ddbd0a8e9fb9d27f848117522a17.
I ran the type check again with the
Unpackfeature enabled:mypy test_unpack.py --enable-incomplete-feature=Unpack. This resulted in the same error:To Reproduce
Expected Behavior
A passing type check
Actual Behavior
INTERNAL ERROR occured, which is asking to raise an issue here. As the last error in the verbose traceback is a
NotImplementedErrorI guess the expected behaviour is not implemented yet. This issue is raised as it's stated in the error message.Your Environment
mypy.ini(and other config files): -The text was updated successfully, but these errors were encountered: