Open Daraan opened 1 month ago
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.
Equivalence between
typing
andtyping_extensions
is something I do not expect, however I think the following example is an exception as the non-equivalence comes as a surprise:Why does this happen?
The 3.11+ backport of
TypeVarTuple
returns a patched instancetvt = typing.TypeVarTuple
, which in turn will unpack totyping.Unpack[Ts]
when__iter__
is used. (Unpack
is backported until 3.11)https://github.com/python/typing_extensions/blob/17d3a37635bad3902c4e913a48d969cbebfb08c3/src/typing_extensions.py#L2473
Possible Fixes
1) Likely bad idea: overwrite
tvt.__iter__
to returntyping_extensions.Unpack
; might cause same problem at other places. 2) Add__eq__
totyping_extensions.Unpack
to equal withtyping.Unpack
. BUT, this will only be valid for the left-hand-side.Fix for the right-hand-side: a)
typing_extensions._UnpackAlias
must inherit fromtyping._UnpackGenericAlias
for right-hand side priority. b) addtyping._UnpackGenericAlias.__eq__
via monkey-patchSideeffects: All
Unpack
and*
-unpacks will be equivalent3) 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?