Settings Management
16 min
Application configuration ("is debug mode on? what's the connection pool size?") often comes from scattered sources — environment variables, a config file, command-line overrides. Loading all of that into a plain dict works, but any typo or wrong-typed value silently becomes a runtime bug later, wherever that setting happens to get used. A typed settings model validates everything up front, at startup, where a bad value fails loudly and immediately instead of causing a confusing bug three function calls deep.
from pydantic import BaseModel
class Settings(BaseModel):
debug: bool = False
max_connections: int = 10
timeout_seconds: float = 30.0
def load_settings(overrides):
settings = Settings(**overrides)
return (settings.debug, settings.max_connections, settings.timeout_seconds)
That last example is exactly why pydantic models are a natural fit for settings specifically -- environment variables are ALWAYS strings, no matter what type the setting conceptually is, so automatic coercion (a numeric string becoming an int) is a real practical convenience here, not just an edge case to worry about.
Given the provided `Settings` model (`debug: bool = False`, `max_connections: int = 10`, `timeout_seconds: float = 30.0`), write `load_settings(overrides)`: construct `Settings(**overrides)` and return `(settings.debug, settings.max_connections, settings.timeout_seconds)`.
Why is a typed model like this a better way to manage application configuration than just using a plain dict of settings?
You can define typed settings with sensible defaults and load overrides through validation, catching bad configuration at startup instead of deep inside application logic.