Uh oh!
There was an error while loading. Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork 132
Description
Equivalence between typing and typing_extensions is something I do not expect, however I think the following example is an exception as the non-equivalence comes as a surprise:
# python 3.11importtypingfromtyping_extensionsimportUnpack, TypeVarTuple, get_type_hintsTs=TypeVarTuple("Ts") deffoo(*x: *Ts): ... print(get_type_hints(foo)['x'] ==Unpack[Ts]) # <--- Falseprint(get_type_hints(foo)['x'] ==typing.Unpack[Ts]) # <--- True# or minimal example:print(next(iter(Ts)) ==Unpack[Ts]) # FalseWhy does this happen?
The 3.11+ backport of TypeVarTuple returns a patched instance tvt = typing.TypeVarTuple, which in turn will unpack to typing.Unpack[Ts] when __iter__ is used. (Unpack is backported until 3.11)
typing_extensions/src/typing_extensions.py
Line 2473 in 17d3a37
| tvt=typing.TypeVarTuple(name) |
Possible Fixes
Likely bad idea: overwrite
tvt.__iter__to returntyping_extensions.Unpack; might cause same problem at other places.Add
__eq__totyping_extensions.Unpackto equal withtyping.Unpack. BUT, this will only be valid for the left-hand-side.print(Unpack[Ts] ==get_type_hints(foo)['x']) # <--- Trueprint(get_type_hints(foo)['x'] ==Unpack[Ts]) # <--- False
Fix for the right-hand-side:
a)typing_extensions._UnpackAliasmust inherit fromtyping._UnpackGenericAliasfor right-hand side priority.
b) addtyping._UnpackGenericAlias.__eq__via monkey-patchSideeffects: All
Unpackand*-unpacks will be equivalentdo not fix, but add a limitation/warning to the documentation that in 3.11
typing_extensions.Unpack[Ts] !=*Ts==typing.Unpack[Ts] # pseudocode
I already have the necessary code for 2.a, but I am not sure what your stance is on this. Should equality be introduced, and if so is subclassing acceptable?