There’s an easy way to view which of your settings deviate from the default
settings. The command pythonmanage.pydiffsettings displays differences
between the current settings file and Django’s default settings.

In your Django apps, use settings by importing the object
django.conf.settings. Example:

fromdjango.confimportsettingsifsettings.DEBUG:# Do something

Note that django.conf.settings isn’t a module – it’s an object. So
importing individual settings is not possible:

fromdjango.conf.settingsimportDEBUG# This won't work.

Also note that your code should not import from either global_settings or
your own settings file. django.conf.settings abstracts the concepts of
default settings and site-specific settings; it presents a single interface.
It also decouples the code that uses settings from the location of your
settings.

Because a settings file contains sensitive information, such as the database
password, you should make every attempt to limit access to it. For example,
change its file permissions so that only you and your Web server’s user can
read it. This is especially important in a shared-hosting environment.

In some cases, you might want to bypass the DJANGO_SETTINGS_MODULE
environment variable. For example, if you’re using the template system by
itself, you likely don’t want to have to set up an environment variable
pointing to a settings module.

In these cases, you can configure Django’s settings manually. Do this by
calling:

Pass configure() as many keyword arguments as you’d like, with each keyword
argument representing a setting and its value. Each argument name should be all
uppercase, with the same name as the settings described above. If a particular
setting is not passed to configure() and is needed at some later point,
Django will use the default setting value.

Configuring Django in this fashion is mostly necessary – and, indeed,
recommended – when you’re using a piece of the framework inside a larger
application.

Consequently, when configured via settings.configure(), Django will not
make any modifications to the process environment variables (see the
documentation of TIME_ZONE for why this would normally occur). It’s
assumed that you’re already in full control of your environment in these
cases.

If you’d like default values to come from somewhere other than
django.conf.global_settings, you can pass in a module or class that
provides the default settings as the default_settings argument (or as the
first positional argument) in the call to configure().

In this example, default settings are taken from myapp_defaults, and the
DEBUG setting is set to True, regardless of its value in
myapp_defaults:

The following example, which uses myapp_defaults as a positional argument,
is equivalent:

settings.configure(myapp_defaults,DEBUG=True)

Normally, you will not need to override the defaults in this fashion. The
Django defaults are sufficiently tame that you can safely use them. Be aware
that if you do pass in a new default module, it entirely replaces the Django
defaults, so you must specify a value for every possible setting that might be
used in that code you are importing. Check in
django.conf.settings.global_settings for the full list.

If you’re not setting the DJANGO_SETTINGS_MODULE environment variable, you
must call configure() at some point before using any code that reads
settings.

If you don’t set DJANGO_SETTINGS_MODULE and don’t call configure(),
Django will raise an ImportError exception the first time a setting
is accessed.

If you set DJANGO_SETTINGS_MODULE, access settings values somehow, then
call configure(), Django will raise a RuntimeError indicating
that settings have already been configured. There is a property just for this
purpose:

If you’re using components of Django “standalone” – for example, writing a
Python script which loads some Django templates and renders them, or uses the
ORM to fetch some data – there’s one more step you’ll need in addition to
configuring settings.

After you’ve either set DJANGO_SETTINGS_MODULE or called
configure(), you’ll need to call django.setup() to load your
settings and populate Django’s application registry. For example:

importdjangofromdjango.confimportsettingsfrommyappimportmyapp_defaultssettings.configure(default_settings=myapp_defaults,DEBUG=True)django.setup()# Now this script or any imported module can use any part of Django it needs.frommyappimportmodels

Note that calling django.setup() is only necessary if your code is truly
standalone. When invoked by your Web server, or through django-admin, Django will handle this for you.