[Django] #31165: Overhaul settings

9 views
Skip to first unread message

Django

unread,
Jan 14, 2020, 5:24:30 AM1/14/20
to django-...@googlegroups.com
#31165: Overhaul settings
----------------------------------------+--------------------------
Reporter: orlnub123 | Owner: nobody
Type: Bug | Status: new
Component: Core (Other) | Version: master
Severity: Normal | Keywords: settings
Triage Stage: Unreviewed | Has patch: 1
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
----------------------------------------+--------------------------
This overhaul fixes a couple of bugs and makes the code simpler. The bugs
it
fixes are:

- Being able to set non-upper attributes directly on the settings object
e.g.:
{{{#!python
from django.conf import settings

settings.foo = 'bar' # Doesn't error
print(settings.foo)
}}}

- Being able to delete the same setting multiple times on user configured
settings e.g.:
{{{#!python
from django.conf import settings

settings.configure()
# Doesn't error
del settings.TEST
del settings.TEST
del settings.TEST
}}}

- `Settings.is_overridden` ignoring set and deleted settings directly on
the settings object e.g.:
{{{#!python
from django.conf import settings

assert settings.is_overridden('TEST')
del settings.TEST
print(settings.is_overridden('TEST')) # True; should be False

assert not settings.is_overridden('TEST2')
settings.TEST2 = 2
print(settings.is_overridden('TEST2')) # False; should be True
}}}

The biggest change is that now user configured settings are evaluated
immediately instead of on-demand via a `__getattr__`. This was done to fix
the second bug in the simplest way. If all settings live in the
`__dict__`, you don't have to fake attribute deletion.

--
Ticket URL: <https://code.djangoproject.com/ticket/31165>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

Django

unread,
Jan 14, 2020, 9:22:14 AM1/14/20
to django-...@googlegroups.com
#31165: Overhaul settings.
------------------------------+--------------------------------------
Reporter: orlnub123 | Owner: nobody
Type: Bug | Status: closed

Component: Core (Other) | Version: master
Severity: Normal | Resolution: invalid

Keywords: settings | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
------------------------------+--------------------------------------
Changes (by felixxm):

* status: new => closed
* resolution: => invalid


Comment:

Django doesn't support
[https://docs.djangoproject.com/en/3.0/topics/settings/#altering-settings-
at-runtime altering settings at runtime], so described modifications are
not support.

--
Ticket URL: <https://code.djangoproject.com/ticket/31165#comment:1>

Django

unread,
Jan 15, 2020, 4:19:37 AM1/15/20
to django-...@googlegroups.com
#31165: Overhaul settings.
------------------------------+--------------------------------------
Reporter: orlnub123 | Owner: nobody
Type: Bug | Status: closed

Component: Core (Other) | Version: master
Severity: Normal | Resolution: invalid

Keywords: settings | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
------------------------------+--------------------------------------

Comment (by orlnub123):

Some packages alter settings after configuration but before runtime, such
as `django-appconf`. I'd even argue that this reduces settings "altered"
at runtime, as all user configured settings are evaluated immediately, so
you can't have properties that would change their output after the fact.

In reality, these fixes probably help more with the tests than user code,
as they're the [https://code.djangoproject.com/ticket/18824 reason]
UserSettingsHolder even has a `__setattr__` and `__delattr__`. This can be
seen in my PR as I've had to fix a test that relied on broken behavior.

--
Ticket URL: <https://code.djangoproject.com/ticket/31165#comment:2>

Reply all
Reply to author
Forward
0 new messages