Skip to content
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

PEP 585 errors should always be enabled #916

Closed
cdce8p opened this issue Feb 4, 2021 · 4 comments
Closed

PEP 585 errors should always be enabled #916

cdce8p opened this issue Feb 4, 2021 · 4 comments
Labels
bug Something isn't working fixed in next version (main) A fix has been implemented and will appear in an upcoming version

Comments

@cdce8p
Copy link

cdce8p commented Feb 4, 2021

Environment data

  • Language Server version: 2021.2.0
  • OS and version: darwin x64
  • Python version: 3.8
  • python.analysis.indexing: true
  • python.analysis.typeCheckingMode: off / basic

Expected behaviour

PEP 585 errors should always be enabled, even if typeCheckingMode: off. Similar to how PEP 604 errors are handled.

Actual behaviour

typeCheckingMode: off
Only PEP 604 errors are shown.

Screen Shot 2021-02-04 at 23 16 48

typeCheckingMode: basic

Screen Shot 2021-02-04 at 23 17 33

Logs

--

Code Snippet / Additional information

var1: list[int]

var2: int | str
@github-actions github-actions bot added the triage label Feb 4, 2021
@erictraut
Copy link
Contributor

Generally, we display parser errors unconditionally, but semantic errors that depend on type information are controlled by the reportGeneralTypeIssues diagnostic rule, which is off by default when typeCheckingMode is "off". We want to avoid showing any type-related errors that are potentially false positives when type checking is disabled.

In this particular case, I think an exception to this rule may be justified because the types in question are builtin types, and I can't think of any circumstance under which we'd generate a false positive error.

@jakebailey do you agree with that assessment?

@jakebailey
Copy link
Member

I agree in general. Syntax errors are definite, but I am trying to think of some false positives. I suppose that this is no worse than getting an operand of | wrong, as it too requires type analysis, right? I'd think we are more likely to infer things as instance types and then hide the error than we are to infer variables to types themselves and then throw this error even in off mode...

@erictraut erictraut added bug Something isn't working fixed in next version (main) A fix has been implemented and will appear in an upcoming version and removed triage labels Feb 5, 2021
@erictraut
Copy link
Contributor

Thanks for the suggestion. This will be addressed in the next release.

@jakebailey
Copy link
Member

This issue has been fixed in version 2021.2.1, which we've just released. You can find the changelog here: https://github.com/microsoft/pylance-release/blob/main/CHANGELOG.md#202121-10-february-2021

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working fixed in next version (main) A fix has been implemented and will appear in an upcoming version
Projects
None yet
Development

No branches or pull requests

3 participants