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

False alarm: reportGeneralTypeIssues #3359

Closed
omidshojaee opened this issue Sep 19, 2022 · 3 comments
Closed

False alarm: reportGeneralTypeIssues #3359

omidshojaee opened this issue Sep 19, 2022 · 3 comments
Labels
fixed in next version (main) A fix has been implemented and will appear in an upcoming version

Comments

@omidshojaee
Copy link

Environment data

  • Language Server version: 2022.9.21
  • OS and version: Windows 10 19044.2006
  • Python version (& distribution if applicable, e.g. Anaconda): 3.10.7

Code Snippet

from django.contrib.auth.models import User

...

user = User.objects.create_user(username, email, password)

...

Repro Steps

  1. XXX

Expected behavior

According to Django documentation my code is valid (https://docs.djangoproject.com/en/4.1/topics/auth/default/#creating-users)

Actual behavior

Pylance highlights the above line and shows this error:

cannot access member "create_user" for type "BaseManager[Any]"
Member "create_user" is unknown PyLance(reportGeneralTypeIssue)

I ignore the error and run the code and it works fine so this is obviously a false alarm.

Logs

XXX
@judej
Copy link
Contributor

judej commented Sep 20, 2022

Thanks for your report. As you noticed, yes, there is a difference in behavior in the insider builds. Specifically, for the insiders releases, we have changed the default type checking setting from off to basic. The type checker warnings might appear to be false positives especially when the code runs fine. The reason for the warnings is because Pylance’s type inference is incorrect or incomplete.

You can turn off type checking with the following setting and that will revert to the old behavior.

python.analysis.typeCheckingMode': 'off

Having type checking turned on has several benefits including catching errors early, spotting otherwise hard to find bugs. However, there are circumstances where type checking would be less advantageous - for example, when the code is a small use-once script. Also, when using libraries (like Django) that use dynamic typing, Pylance would complain about not being able to infer type info. This can become noisy.

So, while I'd encourage you to keep the typechecking at 'basic' or even go to 'strict' for well annotated code and when using well typed libraries, if type checking is not appropriate for your codebase, you can turn it off with the setting above.

In an upcoming release we will make changing type checking mode easier by adding that option right on the status bar.

Look forward to any feedback you have on type checking modes.

@judej judej closed this as completed Sep 20, 2022
@bschnurr bschnurr added the fixed in next version (main) A fix has been implemented and will appear in an upcoming version label Sep 21, 2022
@huynd26
Copy link

huynd26 commented Feb 22, 2023

Seem it still raises the error after set python.analysis.typeCheckingMode': 'off
I have some query set with the related fields, and everything is ok, but today, when working time, the error reportGeneralTypeIssues appears.
example:
image

OS: Ubuntu 20.04.5 LTS
Python: 3.9.15 64bit
Pylance: v2023.2.30

@debonte
Copy link
Contributor

debonte commented Feb 22, 2023

@huynd26, please file a new issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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

5 participants