I think we're OT, but : I had the same fear about settings.py, but good practices will win out. Django does allow a lot of configuration (rather than convention) so your django project will need to hold a lot of settings, but I tend to modularize my settings.py into:

    * settings_env/convention.py
    * settings_env/project.py
    * settings_env/logging.py
    * settings_env/local.py
    * settings_env/dev.py
    * settings_env/staging.py
    * settings_env/production.py

Then my settings.py is just:

    from settings_env.convention  import *
    from settings_env.project      import *
    from settings_env.logging import *
    
    env = os.environ.get('DJANGO_ENV')
    if env == "production" : from settings_env.production   import *
    elif env == "staging"  : from settings_env.staging      import *
    elif env == "dev"      : from settings_env.dev          import *
    else                   : from settings_env.local        import *

There are still a lot of settings, but, at least, they're organized logically. And my convention.py doesn't change from project to project, so I can pretty much ignore that. project.py just contains overrides to the conventions.

Over at Fashiolista.com we do something similar. The setting system has 3 levels. Default, environment and local. Maybe we'll opensource it at somepoint, not yet entirely happy with it though.

how settings.py gets so large is not only a valid problem in of itself, but also symptom of another problem: it is hard (or at least not obvious) to have configuration that can be changed from the admin.

i've considered implementing something that works similarly to the sites contrib app for this, but it always seems that for it to be useful it needs to hook into django internals more than apps "are supposed to".

> it is hard (or at least not obvious) to have configuration that can be changed from the admin.

You are doing settings.py wrong. You should have your own SiteConfig model stored and manipulated in a db.

Settings.py is for static, persistent attributes, not for site-wide variables which need auditing or updated from time to time.

Care to elaborate. I have never worked on php but I am concerned by settings.py clutter.