-
-
Notifications
You must be signed in to change notification settings - Fork 30.4k
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
Empty typing.Tuple #91137
Comments
There are two empty typing.Tuple. They have the same repr but are not equal. >>> from typing import *
>>> t1 = Tuple[()]
>>> t2 = t1.copy_with(())
>>> t1
typing.Tuple[()]
>>> t2
typing.Tuple[()]
>>> t1 == t2
False
>>> t1.__args__
((),)
>>> t2.__args__
() The only differences is that one has empty __args__, while other has __args__ containing an empty tuple. There is a code purposed to make __args__ containing an empty tuple in this case. What is the purpose? It is not pure theoretical question. This affects unpacked TypeVarTuple substitution. With natural implementation Tuple[Unpack[Ts]][()] is not equal to Tuple[()] and I still have not figured which and where code should be added to handle this special case. It would be easier if such special case did not exist. Built-in tuple does not have a special case: >>> tuple[()].__args__
() |
Alas, I have no idea. I don't even recall what copy_with() is for (it was apparently introduced in 3.7). Possibly vopy_with() is wrong here? I imaging some of this has to do with the special casing needed so that repr() of an empty Tuple type doesn't print "Tuple[]" (which IIRC it did, long ago). |
If for repr(Tuple[()]), it is no longer needed. |
I tried out 3.11 on my pyanalyze type checker and got some failures because of this change, because my previous trick for distinguishing between Tuple and Tuple[()] failed. 3.10: >>> from typing import get_args, Tuple
>>> get_args(Tuple[()])
((),)
>>> get_args(Tuple)
() 3.11: >>> from typing import get_args, Tuple
>>> get_args(Tuple[()])
()
>>> get_args(Tuple)
() However, the new behavior is more consistent: get_args(tuple[()]) always returned (). It's also easy enough to work around (just check I'll put a note in the What's New for 3.11 about this change. |
We get a report about broken pickling of empty
All this can be fixed by backporting this change. But it will break pyanalyze. |
This has a special case to handle '()', but the test (whether the 'elements' iterable is truthy) no longer works as it always passes. Instead, always do the join, then test if it's truthy or not, and return the failsafe '()' if not. This addresses one test failure in Instagram#272: ``` _______________________ TestRenderAnnotation.test_render_annotation[Tuple-Tuple[()]] _______________________ tests/test_stubs.py:212: in test_render_annotation assert render_annotation(annotation) == expected E AssertionError: assert 'Tuple[]' == 'Tuple[()]' E - Tuple[()] E ? -- E + Tuple[] ``` Appears to be due to python/cpython#91137 Signed-off-by: Michel Alexandre Salim <michel@michel-slm.name>
In Python 3.11, `get_args(Tuple[()])` returns `()` instead of `((),)`: python/cpython#91137 Change our code to be able to handle this. Address this test failure in ``` _____________________________ TestTypeConversion.test_type_round_trip[Tuple2] ______________________________ tests/test_encoding.py:80: in test_type_round_trip assert type_from_dict(type_to_dict(typ)) == typ E AssertionError: assert typing.Tuple == typing.Tuple[()] E + where typing.Tuple = type_from_dict({'module': 'typing', 'qualname': 'Tuple'}) E + where {'module': 'typing', 'qualname': 'Tuple'} = type_to_dict(typing.Tuple[()]) ``` Signed-off-by: Michel Alexandre Salim <michel@michel-slm.name>
Needs to update the special case for `Tuple[()]` for Python 3.11's python/cpython#91137 Signed-off-by: Michel Alexandre Salim <michel@michel-slm.name>
I was using python 3.10 and getting the same error while using Gemini-Pro-Vision. This resolved my issue - pip install pydantic==1.10.13 |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: