-
-
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
Enable generic NamedTuples #13396
Enable generic NamedTuples #13396
Conversation
This comment has been minimized.
This comment has been minimized.
OK, since I added call syntax support for TypedDicts I also add support for NamedTuples as well. One can use NT = NamedTuple("NT", [("key", int), ("value", T)]) similarly to NT = Tuple[int, T] There is however one problem: I use logic from what we do for proper classes. And it looks like this allows re-using bound type variables (e.g. in nested classes). Interestingly, it is prohibited for type aliases. So they will now be an exception, but also type alias behavior IMO matches PEP 484 specification on this. Anyway, I will not change this now to not break things, but at some point we will need to unify things on type variable binding and reuse. |
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉 |
reveal_type(foo(nts, nti)) # N: Revealed type is "Tuple[builtins.int, builtins.object, fallback=__main__.NT[builtins.object]]" | ||
|
||
reveal_type(foo(nti, x)) # N: Revealed type is "builtins.tuple[builtins.int, ...]" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The difference here (Tuple for fixed-length and builtins.tuple for variable-length) is unfortunate but that seems like a problem for a different PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIRC in error messages we format them nicely, it is only reveal_type()
that reflects the internal representation.
@@ -1,8 +1,19 @@ | |||
from typing import Dict, List | |||
|
|||
import mypy.typeops |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This causes a circular import:
File "venv/lib/python3.10/site-packages/mypy/report.py", line 20, in <module>
from mypy import stats
File "venv/lib/python3.10/site-packages/mypy/stats.py", line 13, in <module>
from mypy.argmap import map_formals_to_actuals
File "venv/lib/python3.10/site-packages/mypy/argmap.py", line 8, in <module>
from mypy.maptype import map_instance_to_supertype
File "venv/lib/python3.10/site-packages/mypy/maptype.py", line 3, in <module>
import mypy.typeops
File "venv/lib/python3.10/site-packages/mypy/typeops.py", line 15, in <module>
from mypy.maptype import map_instance_to_supertype
ImportError: cannot import name 'map_instance_to_supertype' from partially initialized module 'mypy.maptype' (most likely due to a circular import) (venv/lib/python3.10/site-packages/mypy/maptype.py)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for reporting! Do you have a (preferably simple) repro for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Simply importing mypy.report
without mypyc enabled should trigger this issue.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See #13809 Btw just curious, why do you need to import mypy.report
directly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's one of sanity checks in nixpkgs, to make sure mypy module is not broken.
This should help people who need to `import mypy.reports` directly, see #13396 (comment)
Fixes #685
This builds on top of some infra I added for recursive types (Ref #13297). Implementation is based on the idea in #13297 (comment). Generally it works well, but there are actually some problems for named tuples that are recursive. Special-casing them in
maptype.py
is a bit ugly, but I think this is best we can get at the moment.An important note on runtime support for this: IIUC this should work in Python 3.11, and should work soon with
typing_extensions
on earlier versions. I didn't add any version checks here. If someone is interested in adding those, please do this.