#22071 closed Cleanup/optimization (fixed)
Documentation for override_settings needs to explain how code can access overridden settings
Reported by: | Daniele Procida | Owned by: | henkvos |
---|---|---|---|
Component: | Documentation | Version: | dev |
Severity: | Normal | Keywords: | afraid-to-commit |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | yes | UI/UX: | no |
Description
https://docs.djangoproject.com/en/dev/topics/testing/tools/#overriding-settings
If you are writing tests for your own code, and you need to apply override_settings
, and your own code makes use of settings, you need to be careful how you import the settings.
This won't work:
from django.conf import settings SOME_SETTING = settings.SOME_SETTING def some_func(): ... code that does something with SOME_SETTING
because SOME_SETTING
will be set just once, at load time, and override_settings
won't touch it.
Instead, you will need to refer to settings.SOME_SETTING
in your code in order to get hold of the overridden setting:
from django.conf import settings def some_func(): ... code that does something with settings.SOME_SETTING
This should be made clear in the documentation for override_settings
.
(There's a wider issue, in that it's a very common pattern to have a module in an application that gets settings from settings.py
if they're available, and provides sensible defaults if they're not, so the rest of the application can be guaranteed of finding usable settings there:
django.conf import settings SOME_SETTING = getattr(settings, "SOME_SETTING", "some default value")
Settings accessed in this way can't be overridden with override_settings
, which means that an useful Django feature and a well-used Django pattern are incompatible with each other.)
Change History (6)
comment:1 by , 11 years ago
Triage Stage: | Unreviewed → Accepted |
---|---|
Type: | Uncategorized → Cleanup/optimization |
comment:2 by , 11 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:3 by , 11 years ago
Owner: | removed |
---|---|
Status: | assigned → new |
comment:4 by , 11 years ago
Owner: | set to |
---|---|
Status: | new → assigned |
comment:5 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
It's more of a Python concept, but a sentence about this would be helpful. How about: "Avoid aliasing your settings as module-level constants as
override_settings()
won't work on such values since they are only evaluated the first time the module is imported."