[Django] #32764: pass getattr() for settings to the settings module
Django
-----------------------------------------+------------------------
Reporter: Mike Brancato | Owner: nobody
Type: New feature | Status: new
Component: Uncategorized | Version: 3.2
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-----------------------------------------+------------------------
When the Settings class loads the global settings, it roughly does the
following.
1. Uses `importlib` to instantiate the settings module.
2. Iterates thru the upper-case attributes of the module.
3. Assigns the value of the module attribute to an attribute on the
Settings class instance.
`setting_value = getattr(mod, setting)`
This effectively makes dynamic settings impossible. There are probably
many use cases for settings which change during runtime, my use-case is
dynamic credentials that rotate periodically. So I've used features from
PEP-562 (requires Python 3.7) to make certain attributes of a module
dynamic. The only requirement really is that `getattr()` be called on the
module.
Is there any reason that the Settings class could instead maintain a list
of settings and use a `__getattr__` method to check known settings and
pass those to the module?
--
Ticket URL: <https://code.djangoproject.com/ticket/32764>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: Mike Brancato | Owner: nobody
Type: New feature | Status: new
Component: Uncategorized | Version: 3.2
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Description changed by Mike Brancato:
Old description:
> When the Settings class loads the global settings, it roughly does the
> following.
>
> 1. Uses `importlib` to instantiate the settings module.
> 2. Iterates thru the upper-case attributes of the module.
> 3. Assigns the value of the module attribute to an attribute on the
> Settings class instance.
>
> `setting_value = getattr(mod, setting)`
>
> This effectively makes dynamic settings impossible. There are probably
> many use cases for settings which change during runtime, my use-case is
> dynamic credentials that rotate periodically. So I've used features from
> PEP-562 (requires Python 3.7) to make certain attributes of a module
> dynamic. The only requirement really is that `getattr()` be called on the
> module.
>
> Is there any reason that the Settings class could instead maintain a list
> of settings and use a `__getattr__` method to check known settings and
> pass those to the module?
New description:
When the Settings class loads the global settings, it roughly does the
following.
1. Uses `importlib` to instantiate the settings module.
2. Iterates thru the upper-case attributes of the module.
3. Assigns the value of the module attribute to an attribute on the
Settings class instance.
`setting_value = getattr(mod, setting)`
This effectively makes dynamic settings impossible. There are probably
many use cases for settings which change during runtime, my use-case is
dynamic credentials that rotate periodically. So I've used features from
PEP-562 (requires Python 3.7) to make certain attributes of a module
dynamic. The only requirement really is that `getattr()` be called on the
module.
Is there any reason that the Settings class could not instead maintain a
list of settings and use a `__getattr__` method to check known settings
and pass those to the module?
--
--
Ticket URL: <https://code.djangoproject.com/ticket/32764#comment:1>
Django
Reporter: Mike Brancato | Owner: nobody
Component: Core (Other) | Version: 3.2
Severity: Normal | Resolution: duplicate
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Mariusz Felisiak):
* status: new => closed
* resolution: => duplicate
* component: Uncategorized => Core (Other)
Comment:
> Is there any reason that the Settings class could not instead maintain a
list of settings
I don't think it's feasible, settings are not limited to Django's internal
use only. You can define your own settings, 3rd party package can define
their settings etc. I would recommend to start a discussion about using
PEP-562 in settings on DevelopersMailingList where you'll reach a wider
audience.
> my use-case is dynamic credentials that rotate periodically.
See #30178.
Closing as a duplicate.
--
Ticket URL: <https://code.djangoproject.com/ticket/32764#comment:2>