Remove unintentional re-exports

[intgr]

Follow-up from #1308, applying the same to the whole django-stubs code base.

Stub files with from ... import SomeSymbol as SomeSymbol are explicit re-exports (https://typing.readthedocs.io/en/latest/source/stubs.html#imports)

Django does employ intentional re-exports to make imports shorter and more convenient (usually in __init__.py files). But many of these re-exports were under longer module paths. And these unintentional re-exports are likely to be less stable over Django releases. E.g.

# Instead of:
from django.contrib.admin.exceptions import SuspiciousOperation
from django.db.backends.oracle.base import BaseDatabaseWrapper
# Use:
from django.core.exceptions import SuspiciousOperation
from django.db.backends.base.base import BaseDatabaseWrapper

Now mypy will warn users when using these re-exports.

Also cleaned up lots of unused imports in our codebase in the files that I touched.

[ljodal]

I see that you've removed a bunch of imports that are actually present in the Django source code, meaning that mypy will not emit "has not attribute" errors rather than warn about re-exports. Was that intentional? I find it hard to imagine someone actually wants to use any of these, but it might still be nice to match actual runtime behavior and leave the imports in-place with # noqa comments?

[ljodal]

These appear to be present here in the Django source code, so shouldn't they be kept with a # noqa: F401 comment?

[ljodal]

Same as above, this import appears to be present in the source code, so shouldn't this also have a # noqa: F401 comment instead?

[intgr]

I see that you've removed a bunch of imports that are actually present in the Django source code, meaning that mypy will not emit "has not attribute" errors rather than warn about re-exports. Was that intentional?

Good point. It was intentional, but I didn't fully consider that this changes the error message for users.

The difference is error: Module "django.core.cache" has no attribute "ConnectionProxy"

Compared to error: Module "django.core.cache" does not explicitly export attribute "ConnectionProxy"

The question is whether the clarity in error message is sufficient outweigh the maintenance of these legacy imports. I agree the latter is more likely to nudge the user in the direction of "Oh OK, I need to find another place to import this from"

But on the other hand, they were never a stable part of Django's public API and it was an accident they were there. It's inconsistent as well, we don't carry the majority of imports present in Django's own codebase, these removals are exceptions.

Personally I'd prefer not to keep them around, the whole idea of type stubs is to accurately describe the public API surface, and sometimes new mypy errors are expected with stubs releases, as we inch closer to accurately describing the public API surface.

[ljodal]

Alright, sounds good to me. Looking through the list here I'd hope the number of users affected by this is low 🤞

[intgr]

👍 I'll try to remember to mention this in release notes.

[intgr]

Added this to release notes:

Some re-exports that were unintentional have been removed. If you now get errors
like error: Module "django.core.cache" has no attribute "ConnectionProxy",
you probably need to change the module you are importing ConnectionProxy from.
These re-exports were never intentional and are not stable across Django versions.