You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Starred unpack does not equal Unpack in Python 3.11 #485
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:
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)
Fix for the right-hand-side:
a) typing_extensions._UnpackAlias must inherit from typing._UnpackGenericAlias for right-hand side priority.
b) add typing._UnpackGenericAlias.__eq__ via monkey-patch
Sideeffects: All Unpack and *-unpacks will be equivalent
do not fix, but add a limitation/warning to the documentation that in 3.11
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?
I think I'd prefer not to introduce any changes here. I'd prefer to discourage people from relying on equality of derived typing objects; instead introduce introspection APIs (get_origin() etc.) to decompose the objects to see if they are structurally equal.
Activity
JelleZijlstra commentedon Oct 11, 2024
I think I'd prefer not to introduce any changes here. I'd prefer to discourage people from relying on equality of derived typing objects; instead introduce introspection APIs (get_origin() etc.) to decompose the objects to see if they are structurally equal.