id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
25034	Remove attempts to access settings at import time	David Evans	nobody	"There are currently two places (that I can find) in Django where settings are read at import time:
1. [https://github.com/django/django/blob/ec4f219ecb7a5e43d0353633fac4dac42d0ee492/django/core/cache/__init__.py#L32 django/django/core/cache/__init__.py]
2. [https://github.com/django/django/blob/ec4f219ecb7a5e43d0353633fac4dac42d0ee492/django/contrib/staticfiles/urls.py#L17 django/django/contrib/staticfiles/urls.py]

Case 1 is causing some people confusion when attempting to import things in `wsgi.py`, as the import breaks if it comes before `DJANGO_SETTINGS_MODULE` is defined. See for example: [https://github.com/evansd/whitenoise/issues/31#issuecomment-104185649]

This check on the contents of `settings.CACHE` seems to me to be superfluous as failing to define a default cache backend will trigger an `InvalidCacheBackendError` anyway when attempting to access it. I don't see that triggering `ImproperlyConfigured` on import adds much here.

Case 2 seems to be entirely redundant as it's only used for defining `urlpatterns` in that file and I can't find anything which uses this or any mention of it in the docs going back to v1.4. If I remove those lines the tests continue to pass, so I hoping this can be safely removed.

The coding style document [https://docs.djangoproject.com/en/1.8/internals/contributing/writing-code/coding-style/#use-of-django-conf-settings suggests] that such import-time evaluation of settings is to be avoided, and it's causing at least some real-world confusion, so it would be good to clean this up if possible."	Cleanup/optimization	new	Uncategorized	dev	Normal				Unreviewed	0	0	0	0	0	0