我们有一个历史比较悠久的Django网络应用程序，最早是为Django 1.2编写的。那是很久以前的事了，我也不知道自己在做什么，所以当我开始做这个web应用时，我做了Django或多或少建议的事情。我运行'django-admin startproject'来设置初始目录结构和文件，包括包含应用程序各种配置设置的settings.py ，然后开始编辑生成的settings.py ，添加所有我们需要的定制内容。结果发现这是一个小错误。
问题是，Django希望你在settings.py，以及它的结构在不同的Django版本中是不同的；如果你今天重新运行'django-admin startproject'，Django 1.2的settings.py 并不是你会得到的（也不是你真正想要的）。因为我把我们的本地定制混入了settings.py ，我不能只是让Django重新生成它，用最新的Django 1.2版本替换我们的旧版本，这样就能按照Django 1.9的要求来设置。所以当我为Django 1.9重做我们的settings.py ，我重组了它的设置方式，把我们的许多设置放到一个单独的文件里（实际上是一个层叠的文件）。
(我还犯了一个小错误，不小心丢掉了一个我们需要的设置，因为我没有注释它）。
我目前的做法是，只有对Django设置的最小修改才会进入settings.py本身，特别是那些结构化和有序的数据，如INSTALLED_APPS 、MIDDLEWARE 和TEMPLATES 。我们对所有这些设置的修改都有明确的标记，所以当我需要将它们传播到新版本的settings.py 时，我可以找到它们。我们所有的其他设置都进入一个单独的文件（(cslabsettings.py），它在最后被拉入settings.py：
# CSLAB:
# This is where our actual settings live.
from app.cslabsettings import *
这里面有我们应用程序的所有设置，还有一些Django的设置没有在settings.py中设置，所以不需要在那里修改，比如ADMINS (cf)。因为我们把这个文件拉到settings.py ，所有常见的Django的东西都可以工作，不需要特别配置。
在此基础上，我们还有一两层额外的设置文件。在开发中，我有一个settings_dev.py ，它导入了(settings.py)，然后覆盖了一些部分(例如，设置'DEBUG=true')。为了使用它，我有一个manage_dev.py ，它只是修改了标准的manage.py ，以使用settings_dev 。我还有一个settings_wsgi.py ，它包含在WSGI下运行而不是在管理命令中运行的特定设置，还有一个settings_wsgi_dev.py ，是为了明显的事情。
(现在我看了看settings_wsgi.py ，可能它有太多的设置，应该修剪一下。有一连串的设置文件的问题是，很容易失去对什么设置的跟踪，以及什么设置还需要在最新的文件中被覆盖）。
这和我古代的Apache配置的模块化方法是一样的，也是出于同样的原因。Django生成的settings.py 几乎是一个系统提供的文件，这意味着你要定期用一个新的系统提供的版本替换它。你对它的改动越少，当这种情况发生时，你所要做的工作就越少。
(本条目是对本条目末尾那一小段的延迟解释)。
