Support py3.5 style typing annotations

[pylint-bot]

Originally reported by: Anonymous

---

In the very least it would be nice to force type assertions on function arguments (i.e. this is definitely a string)

Would also be cool to support them in py2 via backports.typing or typing packages. The py2 version could even be nice enough to support multiple @annotations decorators for overloads as defined in https://www.python.org/dev/peps/pep-0484/#stub-files .

---

• Bitbucket: https://bitbucket.org/logilab/pylint/issue/647

[pylint-bot]

Original comment by Florian Bruhin (BitBucket: The-Compiler, GitHub: @The-Compiler?):

---

Also see https://bitbucket.org/logilab/astroid/issues/153/investigate-the-use-of-typingpy

[pylint-bot]

Original comment by Claudiu Popa (BitBucket: PCManticore, GitHub: @PCManticore):

---

That's in our roadmap, but it will not happen very soon. There aren't many libraries (or code) which can use PEP 484 annotations, so it's not as urgent as it may seem.

[dstromberg]

+1. I'd love this.

Actually, type annotations have been around since Python 3.0. It's the typing module that's new to 3.5 - but there's a backport.

[PCManticore]

Yes, I was referring to the typing module and its inherent types, rather than function annotations (which we do support, but we don't process them). While this would be useful, it would take some time to have it, I presume a couple of weeks worth of work, which I cannot put into right now. It's definitely on our roadmap for the future.

[WielkiZielonyMelon]

+1

Actually, I have just moved to a new team in my company. The typing hints are used here. I would love to see this feature!

[zrneely]

I'm also interested in this feature! Notably, since pylint is used by default by Syntastic, vim users with that plugin installed will automatically get type checking on each file write.

[Paebbels]

The evaluation of type hints might be needed to solve this issue: protected-access and @classmethod cls.

As I added a type hint in my code (see the linked issue from Landscape.io), pyCharm showed the correct behavior.

[johan-bjareholt]

This would be very nice. Currently using the typing system and doing static checking with mypy. I have landscape.io set up for a github project which currently create a lot of invalid errors due to it using pylint to find these errors and sinks our code health metric a lot due to this. It creates a invalid-sequence-index when for example using def myfunc(arg1: Optional[int], arg2: List[int]) for example.

[marius92mc]

Is there any news on this issue? Any plans of introducing/releasing it?

[PCManticore]

Yes, we do have a plan to implement this feature, what we lack is the time, which is why the issue is still open.

[tiny-dancer]

annual checkup :) - @PCManticore what's the latest?

I see it's added to milestone 5 while 3 and 4 are still in progress. Are there any rough estimates?

Thanks!

[PCManticore]

@tiny-dancer Thanks for the bump, unfortunately the answer is still that we're going to do this someday. I have no rough estimates on anything regarding pylint, as I mostly work on it at most a couple of hours per week.

[Paebbels]

This means, pylint becomes an unusable tool because no active Python version will be supported from March 2019 on? That's the date when Python 3.4 reaches end-of-life and Python 3.5 becomes the lowest actively supported version number.

However, the expectation is that Python 3.4.10 will be released in March of 2019, and this will be the final release of Python 3.4.

Source: https://www.python.org/dev/peps/pep-0429/

I honestly dislike that a tool like pylint hinders developers to use a up-to-date programming language revision. Because of automatic checking tools relying on pylint, we are forced to use old Python code or disable checks.

[troyready]

This means, pylint becomes an unusable tool because no active Python version will be supported from March 2019 on

While this is an important issue to solve, it's not that dire. Many (most?) python projects won't be using type annotations yet, and if it's important to have them then you can still use the comment style annotations instead.

[PCManticore]

@Paebbels I don't know from where you got that impression. We dont support type annotation as in we are not a type checker, this doesn't mean pylint is not usable for you know, what it's name suggests, linting. Please stop with the FUD, if you don't like the general state of things, feel free to contribute financially to the project.

[pietrodn]

Actually it’s not true that you can just use the type comments syntax. If I do:

from typing import Dict
a = {}  # type: Dict[str, int]

Then pylint complains that Dict is imported but unused, since it’s only used in a comment.
Further, Dict needs to be imported for mypy to work.

And there’s no way to disable that pylint warning only for the typing module, AFAIK.
So either I disable the unused import warning globally — but it’s useful! —, or I live with the pylint warnings.

[dstromberg]

def make_used(thing): assert True or thing make_used(Dict)

…

On Thu, Dec 27, 2018 at 11:44 PM Pietro De Nicolao ***@***.***> wrote: Actually it’s not true that you can just use the type comments syntax. If I do: from typing import Dict a = {} # type: Dict[str, int] Then pylint complains that Dict is imported but unused, since it’s only used in a comment. Further, Dict needs to be imported for Mott to work. And there’s no way to disable that pylint warning only for the typing module, AFAIK. So either I disable the unused import warning globally — but it’s useful! —, or I live with the pylint warnings. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#647 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA0yGoylbJQHjX33HeE5ibhg9Gl_Cq4sks5u9cvigaJpZM4JJ6y2> .

-- Dan Stromberg

[troyready]

I think the best workaround for now is just disabling the import check for that line:

from typing import Dict  # pylint: disable=unused-import

[The-Compiler]

On configurations where astroid uses typed-ast, this isn't an issue at all - however, typed-ast doesn't support Python 3.7 yet: python/typed_ast#60

Either way, that issue seems like something different from "pytest should interpret type annotations".

[AWhetter]

Maybe I'm misunderstanding this issue but is this issue requesting what mypy provides? Given the resources that mypy has behind it, it will far outperform anything that we can ever come up with in pylint. I also wouldn't want to try and duplicate efforts on a problem that is already solved by another community standard tool.

[troyready]

I think you might be right @AWhetter .

I thought this issue was about making pylint not just report a syntax-error on files with the new syntax. But that's not an issue anymore (maybe it never was? I thought it was but maybe I'm just going crazy, or had been poorly testing py2 against py3 files?):

troyready@mycomp:~/pylinttest$ cat __init__.py
"""My test module."""
from typing import List, Optional


def myfunc(arg1: Optional[int], arg2: List[int]):
    """Perform myfunc stuff."""
    print(arg1)
    print(arg2)

troyready@mycomp:~/pylinttest$ pipenv run pylint __init__.py

--------------------------------------------------------------------
Your code has been rated at 10.00/10 (previous run: 10.00/10, +0.00)

(obviously pylint run on py2 will still report a syntax-error on this file but that's to be expected.)

I'm inclined to think you're right: this issue might just be about duplicating mypy functionality now, and accordingly I'd agree with your logic about closing it.

[PCManticore]

Hey folks, you might be right, this issue transitioned from something else to supporting type annotation a la mypy. Regardless we can close this issue now, but I'd like to offer my two cents on my we might need to have some type inference support after all.

Right now pylint relies on its own inference engine, which ultimately is somewhat basic. This leads to quite a lot of false positives for deep inspections such as no-member, since what the entire inference is doing is just solving the variables into what values they might represent. In some cases it can properly infer the true value, in other cases we just infer a None or raise an inference error. This leads to quite a few false positives in which we cannot properly deduce the actual types due to the limited inference capabilities.

While mypy is a fully fledged type checker, in our case we only need some support of type inference for function signatures and assignment signatures as well, in which case we could assume the type passed from the type signature instead of relying on our inference. This could also mean better performance, as we won't have to walk the tree calling the inference to figure out the type. A similar project that works in the same vein is jedi which doesn't need to do full type analysis as mypy is doing.

I honestly believe this capability could allow pylint to survive the next 10 years as well, as it will reduce false positives and hopefully improve the performance as well.

Let me know what your thoughts are about this.

[belm0]

my use case:

• I wrote a nice missing-await checker for pylint (in Trio's async/await policy, coroutines should always be immediately consumed by await, so this makes sense)
• but of course the checker can't work on method calls if pylint is lacking the object's type info
• a primary case being class objects passed as type-annotated function args

obviously a "missing-await" check would not be in scope for something like mypy, so here I am

[mohammedi-haroune]

@PCManticore I think it's a pretty good idea and a very important feature that pylint should have.

[iot-resister]

i> I think you might be right @AWhetter .

I thought this issue was about making pylint not just report a syntax-error on files with the new syntax. But that's not an issue anymore (maybe it never was? I thought it was but maybe I'm just going crazy, or had been poorly testing py2 against py3 files?):

troyready@mycomp:~/pylinttest$ cat __init__.py
"""My test module."""
from typing import List, Optional


def myfunc(arg1: Optional[int], arg2: List[int]):
    """Perform myfunc stuff."""
    print(arg1)
    print(arg2)

troyready@mycomp:~/pylinttest$ pipenv run pylint __init__.py

--------------------------------------------------------------------
Your code has been rated at 10.00/10 (previous run: 10.00/10, +0.00)

(obviously pylint run on py2 will still report a syntax-error on this file but that's to be expected.)

I'm inclined to think you're right: this issue might just be about duplicating mypy functionality now, and accordingly I'd agree with your logic about closing it.

@troyready Will this bark if you set pylint to check for annotations , then omit them?

[yhh2021]

I think you might be right @AWhetter .

I thought this issue was about making pylint not just report a syntax-error on files with the new syntax. But that's not an issue anymore (maybe it never was? I thought it was but maybe I'm just going crazy, or had been poorly testing py2 against py3 files?):

troyready@mycomp:~/pylinttest$ cat __init__.py
"""My test module."""
from typing import List, Optional


def myfunc(arg1: Optional[int], arg2: List[int]):
    """Perform myfunc stuff."""
    print(arg1)
    print(arg2)

troyready@mycomp:~/pylinttest$ pipenv run pylint __init__.py

--------------------------------------------------------------------
Your code has been rated at 10.00/10 (previous run: 10.00/10, +0.00)

(obviously pylint run on py2 will still report a syntax-error on this file but that's to be expected.)

I'm inclined to think you're right: this issue might just be about duplicating mypy functionality now, and accordingly I'd agree with your logic about closing it.

Consider,

def queue() -> collections.abc.Iterator[int]:
     ... ...

This raises a

E1136: Value 'collections.abc.Iterator' is unsubscriptable (unsubscriptable-object)

[Pierre-Sassoulas]

I'm going to close, as this issue is clearly "doing the same thing than mypy", and we're clearly not going to handle typing better than mypy. And this seem like a consensus among maintainers.

Any problem with specific false positive or false negative related to typing (like collections.abc.Iterator[int] @yhh2021) should be posted in their own new issue. I opened #4813 to take into account @PCManticore last remark.