Skip to content

--check-untyped-defs-lite #7744

Closed
Closed
--check-untyped-defs-lite#7744

Description

@belm0
belm0
opened on 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.

Activity

  1. ilevkivskyi commented on Oct 18, 2019

    @ilevkivskyi
    ilevkivskyi
    on Oct 18, 2019
    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).

  2. ilevkivskyi
    closed this as completedon Oct 18, 2019

  3. belm0 commented on Oct 18, 2019

    @belm0
    belm0
    on Oct 18, 2019
    ContributorAuthor

    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?

  4. ilevkivskyi commented on Oct 18, 2019

    @ilevkivskyi
    ilevkivskyi
    on Oct 18, 2019
    Member

    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.

  5. rggjan commented on Jan 9, 2020

    @rggjan
    rggjan
    on 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)

  6. rggjan commented on Jan 9, 2020

    @rggjan
    rggjan
    on 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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions