Opened 10 years ago
Last modified 10 years ago
#25034 closed Cleanup/optimization
Remove attempts to access settings at import time — at Version 2
| 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.
The coding style document 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.
Change History (2)
comment:1 by , 10 years ago
| Description: | modified (diff) |
|---|
comment:2 by , 10 years ago
| Description: | modified (diff) |
|---|