Using Django Default Settings with External Configuration

Your approach of importing global_settings to access Django's default values is actually a reasonable solution for your use case, despite the documentation's note about redundancy.

The documentation's warning about not importing from global_settings is primarily referring to standard Django settings files that are loaded through the normal Django settings mechanism. In that context, importing from global_settings is redundant because Django automatically applies those defaults.

However, in your specific scenario where you're:

1. Loading settings from an external TOML file
2. Wanting to fall back to Django defaults when not specified

Using global_settings as a reference point makes sense and is a clean solution.

Alternative Approaches

If you still want to avoid directly importing global_settings, here are some alternatives:

1. Use settings.configure() with defaults

PYTHONCopied
import tomllib
from django.conf import settings

CONFIG_PATH = BASE_DIR / "config.toml"
CONFIG = tomllib.load(CONFIG_PATH.open(mode="rb"))

# Configure settings with Django defaults first, then override with your TOML values
settings_dict = {k: v for k, v in CONFIG.items() if k.isupper()}
settings.configure(default_settings=settings, **settings_dict)

2. Create a utility function to handle defaults

PYTHONCopied
import tomllib
from django.conf import settings, global_settings

CONFIG_PATH = BASE_DIR / "config.toml"
CONFIG = tomllib.load(CONFIG_PATH.open(mode="rb"))

def get_setting(name):
    """Get setting from TOML config or fall back to Django default"""
    if name in CONFIG:
        return CONFIG[name]
    return getattr(global_settings, name)

SESSION_COOKIE_SAMESITE = get_setting("SESSION_COOKIE_SAMESITE")

Conclusion

While Django's documentation advises against importing from global_settings in standard settings files, your use case is different. You're not creating a redundancy in the settings loading process; you're explicitly referencing Django's defaults as fallback values when loading from an external source.

Your current approach is actually a pragmatic solution that avoids hardcoding values while maintaining the ability to track Django's default changes over time.