# Declarative “Settings Objects” (roadmap)

**URL:** https://forum.djangoproject.com/t/declarative-settings-objects-roadmap/45047
**Category:** Django Internals
**Created:** [May 3, 2026, 11:19pm UTC](https://forum.djangoproject.com/t/declarative-settings-objects-roadmap/45047 "2026-05-03T23:19:13Z")
**Posts on this page:** 2
**Page:** 1

<div class="post-metadata">

### Author: ![markwalker](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/markwalker/32/7075_2.png) [@markwalker](https://forum.djangoproject.com/u/markwalker)
#### Post date: [May 3, 2026, 11:19pm UTC](https://forum.djangoproject.com/t/declarative-settings-objects-roadmap/45047/1 "2026-05-03T23:19:13Z")

</div>

Some time ago we had a [roadmap session](https://forum.djangoproject.com/t/informal-roadmap-retrospective-workshops-for-django/26835) in which I said I’d take a look at the idea of declarative “Settings Objects”. The rough outline/idea from the meeting for this was;

> A better way to encapsulate related settings. See the EMAIL\_ settings. Other examples include: various security headers, cookie settings, and I’m sure there are more. A better approach would be some kind of settings object — maybe dataclass based, or similar to those in Pydantic or attrs or elsewhere.

So to first consider those `EMAIL_` settings.

```python
EMAIL_BACKEND = '...'
EMAIL_HOST = 'smtp.example.com'
EMAIL_PORT = 587
EMAIL_USE_TLS = True
EMAIL_HOST_USER = ''
EMAIL_HOST_PASSWORD = ''
EMAIL_TIMEOUT = None

```

They are grouped only by naming convention, with no enforcement/type hints/validation.

Thinking about how this might be improved, I think there may be two potential approaches, where the idea is to not introduce dependencies and trying to keep things familiar.

1. Dataclass-based “settings groups”

2. A lightweight `SettingsGroup`base class

Here are some thoughts on potential settings groups, starting with the email group;

| Group | Prefix | Note |
| --- | --- | --- |
| `EMAIL` | `EMAIL_*` | Likely candidate for initial implementation |
| `CSRF` | `CSRF_*` | Small set of security related settings |
| `SESSION` | `SESSION_*` | Slightly larger - stable API |
| `CACHES` | `CACHES` | Potential for typing |
| `SECURITY` | various - `SECURE_*`, `X_FRAME_*` | Great candidate for grouping |
| `STATICFILES` | `STATIC_*`, `STATICFILES_*` | Useful to group |
| `AUTH` | `AUTH_*`, `LOGIN_*`_,_ `LOGOUT_*` | Big group |

Curious what people’s thoughts are on this.

---

<div class="post-metadata">

### Author: ![jacobtylerwalls](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/jacobtylerwalls/32/30603_2.png) [@jacobtylerwalls](https://forum.djangoproject.com/u/jacobtylerwalls)
#### Post date: [May 4, 2026, 2:21pm UTC](https://forum.djangoproject.com/t/declarative-settings-objects-roadmap/45047/2 "2026-05-04T14:21:51Z")

</div>

(Just a heads up: Django 6.1 [will deprecate the email settings](https://github.com/django/deps/pull/105) in favor of `EMAIL_PROVIDERS`, so you may wish to prototype with something else.)
