settings.py will include the default Django settings, probably the file created by django-admin.py
development.py will hold settings/overwrites needed for the development environment.
The extra settings files (production.py, development.py, etc) will extend the existing settings.py (or another parent file which in turn extends settings.py) and add their own settings customizations.
This could be your development.py file:

easy to create settings for each of your environments (production, development, etc)

it’s a great way to keep your settings organized, easy to find and edit.

easier to reuse your settings for other projects. For example, we could use the same development.py file (as shown above) with other production.py settings.

Cons

you have to change the manage.py and the WSGI file, which might not be possible on your client server.

Other Django settings tips

do not use your project name in the settings, i.e. use ROOT_URLCONF = ‘urls’ and not ROOT_URLCONF = ‘myproject.urls’, use INSTALLED_APPS = (“appname”,) and not INSTALLED_APPS = (“myproject.appname”, ). You will then be able to easily move settings and applications between one project to another

2 Responses so far.

I seem to see “Answer 2″ more and more, where production and development settings configured in the settings/ directory. However, I’m curious as to what one should do with private settings that shouldn’t be committed to version control, such as passwords, api keys, and such.

How do you make this balance of having all variants of the settings, yet keep private data private – do you simply exclude the settings/development.py and settings/production.py from version control, or is there some other strategy? Just curious

As you mentioned, adding the private setting file to the versioning system ignore list will work fine.

Another solution is to place the private file outside the files which go under the versioning system.
One would have to extend the sys.path for the system to find that file.

There is also the possibility of storing the private settings in a database. Along with the setting name and encoded value there will be a public key and a host identification (unique) string (so one can find it’s own settings). Then each developer will use their own private keys to decode the settings.