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.

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