Take type annotation into account when inference fails

[Pierre-Sassoulas]

Current problem

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.

Desired solution

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.

Additional context

Taken from the comment from @PCManticore here

[DanielNoord]

I'm not sure we should actually do this. How would we handle incorrectly typed functions/variables? We would need to run mypy ourselves to make sure the typing is correct.

The biggest benefit of this would be that you can explicitly type stuff that pylint incorrectly infers right now, often due to control flow inference. I think we should focus our efforts on improving the inference, rather than also become a type checker that can sport incorrect typing.

[Pierre-Sassoulas]

(If we use typing I would do it only when inference failed and assume it's correct instead of re-implementing a type checker entirely) But I think control flow capability is indeed more important. The strength of pylint lie in it's inference, so it make sense to make the inference better before trying to use typing as crutches when inference fails.

[DanielNoord]

Indeed! Let's close this: we will likely never close this as it isn't within the current scope of the project and there are far too many things that are within that scope and haven't been fixed yet.

Edit: @Pierre-Sassoulas I saw you mentioned this issue somewhere else. I guess you don't want to close?

[Pierre-Sassoulas]

I see that as a really long term goal. But I think keeping the discussion open permit to point to it when an issue is opened and solvable only by using annotations so we can close the other issue without writting a novel.

[ollie-iterators]

I was wondering why there was no version 4.0 and the milestones skipped from Version 3 to Version 5. Now I am wondering why the version 4.0 milestone was closed before version 3.0.

[Pierre-Sassoulas]

It's a long term goal, putting it in the farther milestone is supposed to convey that, but we could also remove the milestone entirely.

[ollie-iterators]

This is fine. I see that the milestone for 4.0 has been added back.