Crash on simple namedtuple

[rprospero]

The following code caused an internal error on version 0.521. I did a cursory search of the current issue tracker and didn't find anything that matched the simplicity of this case.

from collections import namedtuple
    
HeData = namedtuple("HeData", "run cell scale dt fid t1")

the traceback is:

/home/adam/.local/lib/mypy/typeshed/stdlib/3/typing.pyi:5: error: Module 'types' has no attribute 'CodeType'
/home/adam/.local/lib/mypy/typeshed/stdlib/3/typing.pyi:5: error: Module 'types' has no attribute 'FrameType'
/home/adam/.local/lib/mypy/typeshed/stdlib/3/typing.pyi:5: error: Module 'types' has no attribute 'TracebackType'
types.py:3: error: INTERNAL ERROR -- please report a bug at https://github.com/python/mypy/issues version: 0.521
Traceback (most recent call last):
  File "/home/adam/.local/bin/mypy", line 11, in <module>
    sys.exit(console_entry())
  File "/home/adam/.local/lib/python3.6/site-packages/mypy/__main__.py", line 7, in console_entry
    main(None)
  File "/home/adam/.local/lib/python3.6/site-packages/mypy/main.py", line 50, in main
    res = type_check_only(sources, bin_dir, options)
  File "/home/adam/.local/lib/python3.6/site-packages/mypy/main.py", line 97, in type_check_only
    options=options)
  File "/home/adam/.local/lib/python3.6/site-packages/mypy/build.py", line 196, in build
    graph = dispatch(sources, manager)
  File "/home/adam/.local/lib/python3.6/site-packages/mypy/build.py", line 1801, in dispatch
    process_graph(graph, manager)
  File "/home/adam/.local/lib/python3.6/site-packages/mypy/build.py", line 2044, in process_graph
    process_stale_scc(graph, scc, manager)
  File "/home/adam/.local/lib/python3.6/site-packages/mypy/build.py", line 2139, in process_stale_scc
    graph[id].semantic_analysis()
  File "/home/adam/.local/lib/python3.6/site-packages/mypy/build.py", line 1696, in semantic_analysis
    self.manager.semantic_analyzer.visit_file(self.tree, self.xpath, self.options, patches)
  File "/home/adam/.local/lib/python3.6/site-packages/mypy/semanal.py", line 295, in visit_file
    self.accept(d)
  File "/home/adam/.local/lib/python3.6/site-packages/mypy/semanal.py", line 3645, in accept
    node.accept(self)
  File "/home/adam/.local/lib/python3.6/site-packages/mypy/nodes.py", line 859, in accept
    return visitor.visit_assignment_stmt(self)
  File "/home/adam/.local/lib/python3.6/site-packages/mypy/semanal.py", line 1581, in visit_assignment_stmt
    self.process_namedtuple_definition(s)
  File "/home/adam/.local/lib/python3.6/site-packages/mypy/semanal.py", line 2126, in process_namedtuple_definition
    named_tuple = self.check_namedtuple(s.rvalue, name)
  File "/home/adam/.local/lib/python3.6/site-packages/mypy/semanal.py", line 2162, in check_namedtuple
    info = self.build_namedtuple_typeinfo(name, items, types, {})
  File "/home/adam/.local/lib/python3.6/site-packages/mypy/semanal.py", line 2275, in build_namedtuple_typeinfo
    info = self.basic_new_typeinfo(name, fallback)
  File "/home/adam/.local/lib/python3.6/site-packages/mypy/semanal.py", line 2251, in basic_new_typeinfo
    info.mro = [info] + basetype_or_fallback.type.mro
TypeError: can only concatenate list (not "NoneType") to list

[emmatyping]

Im unable to reproduce this on 0.521, or 0.511. Based on the typing errors, is there, perhaps, a module named types.py or a stub with the same name?

[ilevkivskyi]

@rprospero
This may de a duplicate of #3173 #3131 #3725 #1876

Probably something is wrong with your setup/config, or maybe just an unfortunate file name as @ethanhs said. You could read these issues and see if the proposed solutions work for you.

[ilevkivskyi]

(Update: fixed issue number.)

[rprospero]

Ah, my apologies. ethanhs identified it exactly.

[gvanrossum]

I do think there's an action item for the mypy core team. We ought to verify that of the initial cycle of dependency stubs (including typing.pyi, abc.pyi and builtins.pyi, and a few more depending on Python version) all files in that cycle are loaded from typeshed, not from the user's code. Possibly we could somehow force-load these with only typeshed in the search path?

[ilevkivskyi]

@gvanrossum

I do think there's an action item for the mypy core team. We ought to verify that of the initial cycle of dependency stubs (including typing.pyi, abc.pyi and builtins.pyi, and a few more depending on Python version) all files in that cycle are loaded from typeshed, not from the user's code.

Yes, but IIUC we already have an open issue #1876 for this.