mypy claims that typed code is always still perfectly good ordinary python, but that is not always the case

[mbdevpl]

First of all, I've recently started to annotate my code, and mypy is very helpful in many cases. But I have also found a case where it is not very helpful. Below is a minimal example.

Let's say I have a file foo_module.py:

"""
    Module for class Foo.
"""

import typing

class Foo:
    """ Class Foo. """
    def __init__(self):
        """ Constructs fooo. """
        self.bars = [] # type: typing.MutableSequence[str]
    def append_bar(self):
        """ Appends bar to bars. """
        self.bars.append('bar')
    def clear_bars(self):
        """ Clears bars. """
        self.bars.clear()

if __name__ == '__main__':
    FOO = Foo()
    FOO.bars.append(0) # mypy should detect this

In the above code, I either get "unused import" warning from most static analysis tools (e.g. pylint), or if I actually comment out the first line, to fix the issue, then, in mypy I get "error: Name 'typing' is not defined". I cannot say I want to please everyone, but I just want to avoid being mislead by my code analysis tools.

Specifically:

(1) With import typing intact:

Part of output of pylint foo_module.py, misleading:

************* Module foo_module
W:  5, 0: Unused import typing (unused-import)

Output from mypy foo_module.py, helpful:

foo_module.py:21: error: Argument 1 to "append" of "MutableSequence" has incompatible type "int"; expected "str"

(2) With import typing as comment:

No errors/warnings/etc. from pylint foo_module.py, rating 10/10.

Output of mypy foo_module.py, not very helpful:

foo_module.py: note: In function "__init__":
foo_module.py:11: error: Name 'typing' is not defined

... and no information about this bad behaviour in line 21

Is there any good solution for this?

[PCManticore]

You could ignore the problem with pylint, since it doesn't yet understand PEP 484 (although conceptually that import is not used).

[JukkaL]

Yeah, the problem is that pylint hasn't been updated to support PEP 484. It's probably worth asking pylint developers if they are interested in adding PEP 484 support. # type: comments should be semantically significant for static analyzers and checkers that support PEP 484. Perhaps we should add some language to the PEP regarding linters and other static analysis tools that aren't type checkers.

You can request pylint to ignore the problem like this:

import typing # pylint: disable=unused-import

[mbdevpl]

Thank you very much for your quick reply! Yes, indeed such pylint request will silence the warning. It seems I need to do more reading on my side. I didn't realize that type comments were not only in mypy, but also part of the PEP.

I will ask pylint developers about that issue. In the long run I would like to avoid interfering with pylint's work, because the original code is much more complex, and if some type comments are later changed, I would like pylint to notice that some import really is not used anymore.

Keep up the good work :) Looking forward to non-dev release of mypy :)

[gvanrossum]

I don't think this needs to stay open in the mypy tracker. There's nothing mypy can do, it's up to pylint, until then you can disable pylint for the typing import (we've had to do this for some internal uses too).

[den-run-ai]

here is the cross-ref for the pylint issue, on the roadmap for pylint 2.0:

pylint-dev/pylint#647