Replace aliased imports with their canonical name

[matthiask]

See #1717

When I see a settings variable in a Django project I immediately assume that it's django.conf.settings

When I see dt_settings I have to look it up.

Also, override immediately tells me django.utils.translation.override. If it's not obvious I sometimes import the module and use the function as translation.override but that happens almost never.

It's a low priority issue but I think it should be changed if it's possible without breaking too many pull requests :)

[tim-schilling]

Hmm, I think we're in a difficult place with dt_settings.

Renaming dt_settings to settings indeed makes me think of django.conf.settings and that's not what it would be. It'd be in reference to the debug_toolbar.settings module. Changing debug_toolbar.settings to debug_toolbar.config would remove the alias and not conflict with django.conf.settings, but could impact any downstream toolbars that were using debug_toolbar.settings. I suppose we could reimport from config, and add a deprecation warning if the module is loaded?

I'm totally on board with override and any other aliases though.

[matthiask]

Ah yes, that's right. On second sight I wonder where the dt_settings name even came from, it should at least be dj_settings or something.

I suppose we could reimport from config, and add a deprecation warning if the module is loaded?

Yeah, I think that's the way to go (if we change anything!)

[tim-schilling]

Do you mean from django.conf import settings as dj_settings? Otherwise I'm confused by dj_settings rather than dt_settings.

[matthiask]

Oh, dt_settings are django-debug-toolbar's settings, not Django's settings. I seem to be very confused today. Please forget everything I said about dt_settings vs settings.

[matthiask]

I don't think I care enough; I was very confused and it's so cosmetic as to not matter (much). We can revisit this later if it comes up again but for now I'm going to close this.