Skip to content

Add --allow-untyped-globals flag that avoids partial type errors #5670

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

Merged
merged 7 commits into from
Sep 26, 2018

Conversation

msullivan
Copy link
Collaborator

A major cause of false positives when checking new codebases is
unannotated top level containers and Nones.

Add a flag that suppresses both the "needs type annotation" errors and
the assigning of NoneTyp to variables at the "toplevel" (not when
nested in functions). To avoid throwing away too much type
information, we give more precise types in these situations than
previously, filling in the arguments to the type with Any.

Closes #5639.

I don't love the flag name and would be happy to change it. This just adds an individual flag. Grouping into a --strictness=0 configuration or something we should spin off as another bug, I think.

A major cause of false positives when checking new codebases is
unannotated top level containers and Nones.

Add a flag that suppresses both the "needs type annotation" errors and
the assigning of NoneTyp to variables at the "toplevel" (not when
nested in functions). To avoid throwing away too much type
information, we give more precise types in these situations than
previously, filling in the arguments to the type with `Any`.

Closes #5639.
reveal_type(x) # E: Revealed type is 'builtins.list[Any]'
reveal_type(y) # E: Revealed type is 'builtins.dict[Any, Any]'

[builtins fixtures/dict.pyi]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm curious why this doesn't pass:

class C:
    a = []  # Error here
    def f(self) -> None:
        reveal_type(self.a)

This still gives an error "Need type annotation for 'a'" on line 2.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because member checking has a totally different partial type path apparently, which I'm now going to merge.

@Michael0x2a
Copy link
Collaborator

Just a few thoughts about how we're categorizing this flag:

  1. We should add this flag to the config file docs somewhere -- probably as a per-module option?
  2. One idea is maybe to group this under the "untyped definitions and calls" section and name the flag something like --allow-untyped-globals. (I'm also not happy with this name, but starting the flag with words like "allow/disallow" feels a little more consistent with what the other flags are doing.)

@msullivan
Copy link
Collaborator Author

Re categorization:
The strictness group currently includes only the meta-option --strict, which doesn't seem like the right place for this.
"Untyped definitions and calls" is the closest fit, and I nearly lumped it in there, but it seemed like something of an outlier still. I'd be happy to move it back in there.

@gvanrossum
Copy link
Member

I still think it belongs better in strictness_group. This looks as follows currently:

Other strictness checks:
  --strict                  Strict mode; enables the following flags: --warn-
                            unused-configs, --disallow-subclassing-any,
                            --disallow-untyped-calls, --disallow-untyped-defs,
                            --disallow-incomplete-defs, --check-untyped-defs,
                            --disallow-untyped-decorators, --no-implicit-
                            optional, --warn-redundant-casts, --warn-unused-
                            ignores, --warn-return-any

Copy link
Member

@gvanrossum gvanrossum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yay!

@msullivan msullivan merged commit 87e3c71 into master Sep 26, 2018
@msullivan msullivan deleted the lenient-toplevel branch September 26, 2018 22:18
@gvanrossum gvanrossum changed the title Add a --permissive-toplevel flag that avoids partial type errors Add --allow-untyped-globals flag that avoids partial type errors Oct 12, 2018
@gvanrossum
Copy link
Member

(Note that the flag ended up being renamed to --allow-untyped-globals, but the commit message wasn't adjusted. :-( )

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

Successfully merging this pull request may close these issues.

4 participants