Why is django's settings object a LazyObject?

Question:

Looking in django.conf I noticed that settings are implemented like this:

class LazySettings(LazyObject):     
...

What is the rationale behind making settings objects lazy?

Asked By: pseudosudo

||
Source

Answers:

Its a proxy object that abstracts the actual settings files, and makes it light weight until you actually access the settings you want. Once you start accessing the attributes, it will then load on demand. The idea is to reduce overhead in loading settings until you need them.

Answered By: jdi

I think that the purpose is to simplify settings from a developers point of view. So each project can have its own settings.py file without having the need to define all other Django settings as well. The LazySettings wrapper kind of combines everything from Django global_settings.py and your local settings. It lets the developer decide what settings he wants to overwrite, which he want to keep the defaults or which he wants to add.

The LazySettings class is maybe a wrong name for this, because I think it is not really lazy. Once you do something like from django.conf import settings the whole settings object is in your scope.

Answered By: Torsten Engelbrecht

Check out this section of the Django coding style. The reason is explained in there (quoted below).

In addition to performance, third-party modules can modify settings when they are imported. Accessing settings should be delayed to ensure this configuration happens first.

Modules should not in general use settings stored in
django.conf.settings at the top level (i.e. evaluated when the module
is imported). The explanation for this is as follows:

Manual configuration of settings (i.e. not relying on the
DJANGO_SETTINGS_MODULE environment variable) is allowed and possible
as follows:

from django.conf import settings

settings.configure({}, SOME_SETTING='foo')

However, if any setting is
accessed before the settings.configure line, this will not work.
(Internally, settings is a LazyObject which configures itself
automatically when the settings are accessed if it has not already
been configured).

So, if there is a module containing some code as follows:

from django.conf import settings
from django.core.urlresolvers import get_callable

default_foo_view = get_callable(settings.FOO_EXAMPLE_VIEW)

…then importing
this module will cause the settings object to be configured. That
means that the ability for third parties to import the module at the
top level is incompatible with the ability to configure the settings
object manually, or makes it very difficult in some circumstances.

Instead of the above code, a level of laziness or indirection must be
used, such as django.utils.functional.LazyObject,
django.utils.functional.lazy() or lambda.

Answered By: Michael Mior

Additional information to the accepted answer:

Because we have both django/conf/global_settings.py setting which is the default global setting and site-specific setting which is configured via DJANGO_SETTINGS_MODULE environment variable, we need to have an object that handles the priority stuff of individual settings and abstract away this process. We shouldn’t do that ourselves. It also decouples the code that uses settings from the location of your settings.

So an object is needed!

With that being said, why this object is lazy? Because it lets third-parties to configure the setting manually.

But how? Third-parties do that by settings.configure() method. They can only do that if the settings haven’t already been loaded:

    def configure(self, default_settings=global_settings, **options):
        """
        Called to manually configure the settings. The 'default_settings'
        """
        if self._wrapped is not empty:
            raise RuntimeError("Settings already configured.")

And as a consequence, Django’s documentation said:

Modules should not in general use settings stored in
django.conf.settings at the top level (i.e. evaluated when the module
is imported)

Why? If they do, in the __getattr__ method of this object, there is a checking that loads the settings if it hasn’t already been loaded:

    def __getattr__(self, name):
        """Return the value of a setting and cache it in self.__dict__."""
        if (_wrapped := self._wrapped) is empty:
            self._setup(name)    #########

So it has to be lazy… Lazy means when an instance of the LazySettings class is instantiated, no settings will be configured.

Answered By: S.B