Opened 9 years ago
Last modified 9 years ago
#25034 closed Cleanup/optimization
Remove attempts to access settings at import time — at Version 1
| Reported by: | David Evans | Owned by: | nobody |
|---|---|---|---|
| Component: | Core (System checks) | Version: | dev |
| Severity: | Normal | Keywords: | |
| Cc: | me@…, tom@… | Triage Stage: | Accepted |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | yes | UI/UX: | no |
Description (last modified by )
There are currently two places (that I can find) in Django where settings are read at import time:
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.
If we could remove these two cases then we have the simple rule that settings are not to be accessed at import time, and we won't have any subtle import-order requirements.