AttributeError: 'NoneType' object has no attribute 'accept'

[alunduil]

This is possibly due to missing or outdated pyi files for colorama but reporting here to make sure it doesn't get lost. The trace is included below.

This was the result of running on a largish code base with --use-python-path where colorama is included as an indirect dependency.

Any pointers as to how to begin troubleshooting would be appreciated; I'm going to begin by investigating the typeshed for colorama.

Traceback (most recent call last):
  File "/usr/lib/python-exec/python3.4/mypy", line 6, in <module>
    main(__file__)
  File "/usr/lib64/python3.4/site-packages/mypy/main.py", line 52, in main
    res = type_check_only(sources, bin_dir, options)
  File "/usr/lib64/python3.4/site-packages/mypy/main.py", line 100, in type_check_only
    python_path=options.python_path)
  File "/usr/lib64/python3.4/site-packages/mypy/build.py", line 207, in build
    dispatch(sources, manager)
  File "/usr/lib64/python3.4/site-packages/mypy/build.py", line 1180, in dispatch
    process_graph(graph, manager)
  File "/usr/lib64/python3.4/site-packages/mypy/build.py", line 1298, in process_graph
    process_stale_scc(graph, scc)
  File "/usr/lib64/python3.4/site-packages/mypy/build.py", line 1328, in process_stale_scc
    graph[id].type_check()
  File "/usr/lib64/python3.4/site-packages/mypy/build.py", line 1162, in type_check
    manager.type_checker.visit_file(self.tree, self.xpath)
  File "/usr/lib64/python3.4/site-packages/mypy/checker.py", line 416, in visit_file
    self.accept(d)
  File "/usr/lib64/python3.4/site-packages/mypy/checker.py", line 457, in accept
    typ = node.accept(self)
  File "/usr/lib64/python3.4/site-packages/mypy/nodes.py", line 896, in accept
    return visitor.visit_try_stmt(self)
  File "/usr/lib64/python3.4/site-packages/mypy/checker.py", line 1762, in visit_try_stmt
    self.accept(s.else_body)
  File "/usr/lib64/python3.4/site-packages/mypy/checker.py", line 457, in accept
    typ = node.accept(self)
  File "/usr/lib64/python3.4/site-packages/mypy/nodes.py", line 715, in accept
    return visitor.visit_block(self)
  File "/usr/lib64/python3.4/site-packages/mypy/checker.py", line 1133, in visit_block
    self.accept(s)
  File "/usr/lib64/python3.4/site-packages/mypy/checker.py", line 457, in accept
    typ = node.accept(self)
  File "/usr/lib64/python3.4/site-packages/mypy/nodes.py", line 462, in accept
    return visitor.visit_func_def(self)
  File "/usr/lib64/python3.4/site-packages/mypy/checker.py", line 601, in visit_func_def
    'redefinition with type')
  File "/usr/lib64/python3.4/site-packages/mypy/checker.py", line 2147, in check_subtype
    if not is_subtype(subtype, supertype):
  File "/usr/lib64/python3.4/site-packages/mypy/subtypes.py", line 49, in is_subtype
    return left.accept(SubtypeVisitor(right, type_parameter_checker))
AttributeError: 'NoneType' object has no attribute 'accept'

*** INTERNAL ERROR ***

/usr/lib64/python3.4/site-packages/colorama/win32.py:97: error: Internal error -- please report a bug at https://github.com/python/mypy/issues

NOTE: you can use "mypy --pdb ..." to drop into the debugger when this happens.

[gvanrossum]

What's in colorama/win32.py at line 97? By asking mypy to analyze a large new codebase you've probably triggered some random mypy bug. You might turn of --use-python-path; it's usually better to ignore 3rd party modules for which no stubs exist than trying to analyze the whole library. Maybe --silent-imports would be helpful instead.

[alunduil]

colorama/win32.py:97:

    def winapi_test():
        handle = handles[STDOUT]
        csbi = CONSOLE_SCREEN_BUFFER_INFO()
        success = _GetConsoleScreenBufferInfo(
            handle, byref(csbi))
        return bool(success)

Nothing that seems too out of the ordinary unless the implicit None return is causing the uses to error out (is that a reasonable hypothesis)?

The reason I added --use-python-path was due to types used from library packages not being defined:

infrastructuremanager/api/__init__.py:102: error: Name 'asyncio.BaseEventLoop' is not defined

Perhaps I simply have a misunderstanding of the use of MYPYPATH?

With --silent-imports I got differing output (only slightly) from the invocation without --use-python-path. Using both seems to be very similar to the output I get from --silent-imports alone. All three of which do not result in an error originating in colorama but do include the error indicating asyncio.BaseEventLoop is not defined.

An ancillary question to this (I can move this line of discussion elsewhere if that's better), when I import a type from a library (e.g. asyncio), isn't it resolvable by mypy the same way python would resolve? If so, one would expect that those types would be available for use but not necessarily type checked. If that's not the case then I'll have to review the documentation.

[gvanrossum]

when I import a type from a library (e.g. asyncio), isn't it resolvable by mypy the same way python would resolve?

It could, but usually this isn't what you want, because the asyncio library isn't marked up with type annotations (yet).

Instead, mypy defaults to using stubs (https://www.python.org/dev/peps/pep-0484/#stub-files) that it gets from a repo named typeshed (https://github.com/python/typeshed/).

The reason you get an error on BaseEventLoop is that the stubs for asyncio are incomplete. You can shut this up temporarily by adding # type: ignore to the line that triggers the error. We should update the stub though -- perhaps you're interested in contributing?

Regarding the colorama library, ideally we should get stubs for that too. Even once we fix the crash, mypy wouldn't get that much information out of parsing the unannotated colorama files.

I don't know what's wrong with that code either; most likely something else in the file (or even in something it imports) is the true cause.

For posterity I'll link to that line in the colorama repo: https://github.com/tartley/colorama/blob/master/colorama/win32.py#L97

[gvanrossum]

Pretty sure this is a dupe of #1289.

[alunduil]

@gvanrossum,

The reason you get an error on BaseEventLoop is that the stubs for asyncio are incomplete. You can shut this up temporarily by adding # type: ignore to the line that triggers the error. We should update the stub though -- perhaps you're interested in contributing?

More than happy to. Should I just start looking through typeshed and ensuring that aiohttp has proper entries?

[gvanrossum]

Go for it.