Pylint: Have a way to require type annotations

[murali42]

Is your feature request related to a problem?

Having type annotations makes the code more understandable.
Having a way to require methods have type annotations would be a great start.

Describe the solution you'd like

An option which enforces presence of type annotations.
Where should they be present?

• Methods: All/public only
• Variables: all/public/constant
  For methods.. What part of the signature should the enforcement be for?
  
  
  
  • arguments? return type? (of course self should be exempt)
    
    Any standard set of exemptions?
  
  
  • methods with certain decorators may be exempt (eg. @override implementation of an method from parent class?)
  
  

Additional context

This should be opt-in, i.e. disabled by default (for backward compatibility), so individuals can enable it on a per-file basis (or a flag to pylint binary)

[TylerYep]

This seems better-suited (and already implemented) in mypy --strict, or in various sub-settings. I don't think Pylint needs to duplicate this functionality, and if it did, it would likely slow the linting process by a significant amount.

[ssbr]

I don't think I agree with that: the type checker is for correctness issues, this is basically a pure style issue. In particular, type checkers don't concern themselves with what is a public vs private function, but e.g. the Google Python Style Guide only requires it for (new) public functions, and I expect that kind of differentiation to be common. Type annotations are significantly less useful/important for private functions.

Also, if it's placed in the type checker, that needs to be duplicated once per type checker (not just mypy, but also e.g. pytype, pyre, pycharm), and they might diverge from the linter on what counts as a function that requires type annotations. (For example, a purely name-based approach might accidentally mark an inner function as public.) The logic for "is it public" logic is complicated, but "does it have type annotations" is not -- so I think this kind of check is best placed in the code analysis tools that differentiate between public and private, like the linter.

it would likely slow the linting process by a significant amount.

Can you explain more? pylint/astroid already parses type annotations, so this would only check if those annotations exist at all, which is relatively fast -- for example, to check if a return type annotation exists, it should be enough to check f.returns is not None.

[TylerYep]

Oh, I didn't realize that pylint already parsed type annotations - in that case, this seems like a perfectly valid idea then.

[hippo91]

@murali42 thanks for this suggestion that i find very interesting.
@PCManticore @Pierre-Sassoulas @AWhetter what do you think about it?

[Pierre-Sassoulas]

It make sense, I've made the comment "Let's add typing to new functions" multiple time in review lately, let's automate it :) I think there is no need to make a distinction between function typing and return typing, if we want to have typing on function we also want to have typing on the function return. Also we might make two messages public-function-without-typing and private-function-without-typing (same for public argument) so typing for private function/argument can be enabled by enabling the message without having to add an option to pylint.

[AWhetter]

Sounds good to me. I like these suggestions.