-
Notifications
You must be signed in to change notification settings - Fork 767
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
Django generic views are not recognized if imported with "from django.views import generic" statement #234
Comments
This should be working, because https://github.com/typeddjango/django-stubs/blob/master/django-stubs/views/generic/__init__.pyi declares that |
Returning to this, @erictraut Do you know if this file needs to explicitly re-export the Maybe this code was valid due to some import side effect, but that'd strike me as strange to allow |
The current stub is doing something very strange. It's implicitly importing (and re-exporting) the submodule ".generic.base", but it's not implicitly or explicitly importing/exporting the submodule ".generic". I think the correct fix here is to change the stub to: from .generic.base import View as View
from . import generic as generic |
Type stubs are meant to be very explicit about which symbols are exported from where. By default, imported symbols are not re-exported, and submodules are not implicitly re-exported. |
I don't know what's different between this case and say urllib: https://github.com/python/typeshed/tree/master/stdlib/urllib Its I don't think this is a case where the submodule needs to explicitly be re-exported; I'm not writing: import django.views
django.views.generic That does require a re-export. In fact, if you remove the contents of |
That last case to me says there's a bug where it's hiding |
The statement Likewise, the statement The Python module loader unfortunately has a bunch of side effects that developers sometimes unknowingly rely upon. This is dangerous and fragile, and pyright intentionally honors only the explicit intent of an import statement. In this case, the stub includes the statement |
This comment has been minimized.
This comment has been minimized.
This should be fixed in the next release. |
This issue has been fixed in version 2021.4.3, which we've just released. You can find the changelog here: https://github.com/microsoft/pylance-release/blob/main/CHANGELOG.md#202143-29-april-2021 |
When Django's generic views are imported with the statement
from django.views import generic
and referred to withgeneric.TemplateView
Pylance shows error: "TemplateView" is not a known member of module.Environment data
Expected behaviour
Following code not cause an issue:
Actual behaviour
This code causes error by Pylance.
Error:
Code Snippet / Additional information
First of all, line
from django.views import generic
is not the recommended way of importing generic views in Django.In current version of the Django documentation it is only mentioned on the Step 4 of the tutorial.
If TemplateView is imported like this
from django.views.generic.base import TemplateView
there is no error and no problem.But looking through our 7 year old project (we recently switched to absolutely fabulous and amazing Pylance) we always used
from django.views import generic
code.And looking through the GitHub there are 32,008 code results for the string "from django.views import generic".
So the import maybe wrong and not officially recommended but it works and used by a lot of projects.
Is there any possibility that Pylance will be able to parse the code inside django.generic.views to understand where those classes coming from?
The text was updated successfully, but these errors were encountered: