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
fromtypingimportNamedTupleF= [('x', int)]
A=NamedTuple('A', F) # List or tuple literal expected as the second argument to namedtuple()deff(a: A):
reveal_type(a) # Revealed type is 'Tuple[, fallback=t.namedtuple]'
The first error is expected. But when we silence it, we see that the fallback type generated in this case is not collections.namedtuple but t.namedtuple (t.py was the filename I used).
The problem is that the fallback type ends up in the incremental cache, resulting in tracebacks when incremental mode is used like this:
Traceback (most recent call last):
File "/usr/lib/python3.5/runpy.py", line 184, in _run_module_as_main
"__main__", mod_spec)
File "/usr/lib/python3.5/runpy.py", line 85, in _run_code
exec(code, run_globals)
File "/home/user/src/server/.mypy/venv/lib/python3.5/site-packages/mypy/__main__.py", line 11, in <module>
main(None)
File "/home/user/src/server/.mypy/venv/lib/python3.5/site-packages/mypy/main.py", line 66, in main
res = type_check_only(sources, bin_dir, options)
File "/home/user/src/server/.mypy/venv/lib/python3.5/site-packages/mypy/main.py", line 119, in type_check_only
options=options)
File "/home/user/src/server/.mypy/venv/lib/python3.5/site-packages/mypy/build.py", line 212, in build
graph = dispatch(sources, manager)
File "/home/user/src/server/.mypy/venv/lib/python3.5/site-packages/mypy/build.py", line 1939, in dispatch
process_graph(graph, manager)
File "/home/user/src/server/.mypy/venv/lib/python3.5/site-packages/mypy/build.py", line 2219, in process_graph
process_fresh_scc(graph, prev_scc, manager)
File "/home/user/src/server/.mypy/venv/lib/python3.5/site-packages/mypy/build.py", line 2296, in process_fresh_scc
graph[id].fix_cross_refs()
File "/home/user/src/server/.mypy/venv/lib/python3.5/site-packages/mypy/build.py", line 1656, in fix_cross_refs
self.manager.options.quick_and_dirty)
File "/home/user/src/server/.mypy/venv/lib/python3.5/site-packages/mypy/fixup.py", line 22, in fixup_module_pass_one
node_fixer.visit_symbol_table(tree.names)
File "/home/user/src/server/.mypy/venv/lib/python3.5/site-packages/mypy/fixup.py", line 84, in visit_symbol_table
self.quick_and_dirty)
File "/home/user/src/server/.mypy/venv/lib/python3.5/site-packages/mypy/fixup.py", line 284, in lookup_qualified_stnode
assert key in names, "Cannot find %s for %s" % (key, name)
AssertionError: Cannot find namedtuple for metaserver.lib.deletion_filter.namedtuple
The text was updated successfully, but these errors were encountered:
Example:
The first error is expected. But when we silence it, we see that the fallback type generated in this case is not
collections.namedtuple
butt.namedtuple
(t.py
was the filename I used).The problem is that the fallback type ends up in the incremental cache, resulting in tracebacks when incremental mode is used like this:
The text was updated successfully, but these errors were encountered: