Skip to content

--check-untyped-defs-lite #7744

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
belm0 opened this issue Oct 18, 2019 · 5 comments
Closed

--check-untyped-defs-lite #7744

belm0 opened this issue Oct 18, 2019 · 5 comments

Comments

@belm0
Copy link

belm0 commented Oct 18, 2019

This is a feature request for a mechanism allowing projects to benefit more from partial typing-- for example, typing of commonly used API's. (I envision it as a "lite" version of --check-untyped-defs.)

use case

We have a project where there is a core API written by software engineers, while the bulk of the application uses those API's and is written by non-specialists (animators, researchers, etc.). (I don't think this scenario is uncommon.)

So far we only employ type hints sparingly, as a convenience for IDE autocompletion. For us, mypy is used merely to check for typos and syntax errors on the type annotations themselves.

We aren't motivated to add type hints to our common API's because mypy won't use that information unless the API usage sites themselves have type annotations. But it's not feasible for the non-specialist application authors to write and maintain such annotations.

So I would like to see mypy offer a way to use info from typed API's as much as possible (say to the extent of type inference available at the usage sites), without requiring annotations at the usage sites.

proposal

Add an option --check-untyped-defs-lite which will:

  • like --check-untyped-defs, enable type checking on code which does not have type annotations
  • but will limit checks and/or error output of said unannotated code to uses of API's having type annotations. For example:
    • access of unknown attribute foo.bar in typed module foo
    • call of typed function foo.baz() with incorrect number of arguments
    • call of typed function foo.baz() with incorrectly typed arguments (as far as can be inferred at the call site)
    • typed mismatch when assigning result of typed function foo.baz() to a variable of known type

So unlike --check-untyped-defs, --check-untyped-defs-lite will never emit errors such as "Need type annotation for ..." and "Cannot determine type of ...".

summary

This feature would allow an untold number of projects to benefit from using mypy even without having type annotations in their own code. It would strongly motivate more API's to be type annotated-- both 3rd party and a project's own common API.

@ilevkivskyi
Copy link
Member

As of current master, mypy doesn't require annotations inside untyped functions (when you use --check-untyped-defs). So essentially what you need can be achieved by combining two flags: --check-untyped-defs --allow-untyped-globals. "Cannot determine type" still can happen in this scenario, although really rarely and it would typically indicate something fishy is going on.

Also we try to limit new mypy flags (instead, a meta-flag allow/disabling specific error codes is on our roadmap).

@belm0
Copy link
Author

belm0 commented Oct 18, 2019

As of current master

I'm using master

$ mypy --version
mypy 0.750+dev.0ba1d99e3a0a483acfa520238f5febaf652f98b4

mypy doesn't require annotations inside untyped functions (when you use --check-untyped-defs)

It doesn't match my observation.

$ mypy --check-untyped-defs foo/ | grep 'Need type annotation' | wc -l
70

I confirmed that the errors are coming from untyped functions.

So essentially what you need can be achieved by combining two flags: --check-untyped-defs --allow-untyped-globals

--allow-untyped-globals has no impact on my total error count

$ mypy --check-untyped-defs foo/
Found 578 errors in 137 files (checked 523 source files)

$ mypy --check-untyped-defs --allow-untyped-globals foo/
Found 578 errors in 137 files (checked 523 source files)

a meta-flag allow/disabling specific error codes is on our roadmap

It doesn't seem as simple as globally filtering some error types. We only want the errors suppressed when they are originating from untyped functions.

@ilevkivskyi Is there no merit to keeping this request open so that other people may consider it?

@ilevkivskyi
Copy link
Member

ilevkivskyi commented Oct 18, 2019

It doesn't match my observation.

Do you have a repro?

Is there no merit to keeping this request open so that other people may consider it?

Let's first be sure the same can't be achieved using existing flags.

@rggjan
Copy link

rggjan commented Jan 9, 2020

I can also see that issue quite a lot. The most commen examples:

def foo():
    data = { # error: Need type annotation for 'data'
        'abc': {}
    }

Or

def bar(images):
    pass

def foo():
    images = [] # error: Need type annotation for 'images' (hint: "images: List[<type>] = ...")
    bar(images)

@rggjan
Copy link

rggjan commented Jan 9, 2020

My main use case is that I'd like to enforce quite strict typing rules for all my production code, but be not so strict in tests.

Nevertheless, I want to typecheck the tests as far as possible with check-untyped-defs.

Or is there another way to disable all need type annotation for errors (that I could use in our tests)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants