Mypy complains about empty __all__ being untyped

[mwgamble]

Bug Report

Mypy complains when __all__ is empty, because it can't infer the type of an empty list. This should be unnecessary, as the type of __all__ should already be known ahead of time.

If you attempt to type it while following PEP8, you run into more problems. The import for List (from typing import List) must come after the __all__ assignment. This means you must also write from __future__ import annotations, or wrap the type in a string if you need to support python3.6.

To Reproduce

Add __all__ = [] to a file, and run mypy on that file.

Expected Behavior

I would expect mypy to have a built-in understanding of __all__ given its use by the python runtime. It should therefore not report a typing issue when the list is empty.

Actual Behavior

I get the following error message from mypy:

error: Need type annotation for '__all__' (hint: "__all__: List[<type>] = ...")

Your Environment

• Mypy version used: 0.800
• Mypy command-line flags: None
• Mypy configuration options from mypy.ini (and other config files): None
• Python version used: 3.9
• Operating system and version: Arch Linux

[esoma]

I had fixed this locally before, but dumped it after realizing that you can just use an empty tuple instead. iirc it just forced module level __all__ to be List[str] if it was List[<nothing>], which seems safe to me. I'll see what I can do about a PR. Another way is just allowing List[<nothing>] but that doesn't fix it if someone does something odd like this:

__all__ = []

from typing import List

def add_foo(all: List[str]) -> None:
    all.append('foo')
    
add_foo(__all__)

It's worth noting that if you modify an empty list __all__ in a "normal" way it works just fine, so the bug isn't preventing this relatively common pattern:

__all__ = []
__all__.append('foo')

[denballakh]

Similar issue:

class X:
    __slots__ = [] # error