-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Use join to calculate better fallback for tuples #3575
Comments
Remind me where the fallback type is used? I already think we're being too strict in some cases, e.g. a = (1, 2)
b = a + ('', '') give an error on the second line Also, this is still an error: from typing import Tuple
a = (1, 2)
b = a + ('', '') # type: Tuple[int, int, str, str] There are actually two errors even:
|
The most important places are probably in We of course could be more flexible with tuples, and there are issues for this like #224, this could be done by special-casing. A more "broad" solution for such situations may be variadic generics. Anyway, both these ways are mostly unrelated to the joins in fallbacks. |
The fallback |
Forward references didn't work with anything apart from classes, for example this didn't work: ``` x: A A = NamedTuple('A', [('x', int)]) ``` The same situation was with `TypedDict`, `NewType`, and type aliases. The root problem is that these synthetic types are neither detected in first pass, nor fixed in third pass. In certain cases this can lead to crashes (first six issues below are various crash scenarios). This fixes these crashes by applying some additional patches after third pass. Here is the summary of the PR: * New simple wrapper type `ForwardRef` with only one field `link` is introduced (with updates to type visitors) * When an unknown type is found in second pass, the corresponding `UnboundType` is wrapped in `ForwardRef`, it is given a "second chance" in third pass. * After third pass I record the "suspicious" nodes, where forward references and synthetic types have been encountered and append patches (callbacks) to fix them after third pass. Patches use the new visitor `TypeReplacer` (which is the core of this PR). Fixes #3340 Fixes #3419 Fixes #3674 Fixes #3685 Fixes #3799 Fixes #3836 Fixes #3881 Fixes #867 Fixes #2241 Fixes #2399 Fixes #1701 Fixes #3016 Fixes #3054 Fixes #2762 Fixes #3575 Fixes #3990
Hm, actually this issue was fixed by #3952 only partially: the first bullet in the first message is still missing. Precise fallbacks are generated only for named tuples, not for "normal" tuples, the latter still have |
Just a note (mostly to myself), when updating the fallbacks in patches we should take care that it doesn't interfere with subclassing "normal" tuples: class B:
attr: int
class C(B, Tuple[int, str]):
label: str (The patch is therefore probably should be made in semananl.py, where we know the context for |
Adding the patch is easy here, but this reveals several other errors/bugs, so it is not easy after all. Also |
This was essentially fixed by #6442 |
Currently the fallback of named tuple types and tuples is
Tuple[Any, ...]
but we could use join of items to get a more precise fallback type after #3560 has been merged.Pointers:
tuple_type
inmypy.typeanal
.build_namedtuple_typeinfo
inmypy.semanal
.The text was updated successfully, but these errors were encountered: