Django的settings文件部分源码分析

Django的settings文件部分源码分析

在编写Django项目的过程中, 其中一个非常强大的功能就是我们可以在settings文件配置许多选项来完成我们预期的功能, 并且这些配置还必须大写, 否则就不会生效. 此外, Django自身还有一套更详细的配置, 那Django是如何做到用户配置了相关配置就使用用户的配置, 否则就使用自己默认的配置. 带着这样的疑问, 去查看了用户配置项相关的源码部分.

过程分析

首先启动Django项目, 一般Django都是通过python manage.py runserver这句命令启动的. 从这个入口函数出发, 主要执行了下面3句话.

if __name__ == "__main__":
    # settings文件配置到环境变量
    os.environ.setdefault("DJANGO_SETTINGS_MODULE", "auth_learn.settings")
    from django.core.management import execute_from_command_line
    # 解析并执行命令行参数
    execute_from_command_line(sys.argv)

上面会将我们用户的配置文件(项目下的settings文件)设置到当前环境变量里面.

顺着代码的流程下去.

def execute_from_command_line(argv=None):
    """
    运行了一个命令管理工具, 将命令行的参数传到这个对象中, 并执行
    """
    utility = ManagementUtility(argv)
    utility.execute()

继续往下运行

def execute(self):
    # 解析命令行参数列表的第一个参数
    subcommand = self.argv[1]
    parser = CommandParser(None, usage="%(prog)s subcommand [options] [args]", add_help=False)
    options, args = parser.parse_known_args(self.argv[2:])
    handle_default_options(options)
    ...

    try:
        # 这句话就是重点了, 开始加载app
        settings.INSTALLED_APPS
    except ImproperlyConfigured as exc:
        self.settings_exception = exc

    ...

看到这, 终于看到了和settings文件相关的代码了. 跟进去.

settings = LazySettings()

看到了settings是一个懒加载(延时加载)的LazySettings类的实例对象.

继续跟进LazySettings的定义

class LazySettings(LazyObject):
    def _setup(self, name=None):
        settings_module = os.environ.get(ENVIRONMENT_VARIABLE)
        self._wrapped = Settings(settings_module)
   def __getattr__(self, name):
        if self._wrapped is empty:
            self._setup(name)
        val = getattr(self._wrapped, name)
        self.__dict__[name] = val  # 用到了直接缓存到__dict__里面
        return val
    ...

发现LazySettings类继承自LazyObject, 本身并没有__init__方法, 所以继续往父类跟进

 _wrapped = None
 def __init__(self):
    self._wrapped = empty

父类什么也没有定义, 就是一个空对象. 所以settings对象初始化后什么属性也没有, 这时候Django调用settings.INSTALLED_APPS这句话就是懒加载的核心. 所谓懒加载,就是在需要用到的时候再加载. 一般手段有代理类,线程... Django中使用 LazyObject 代理类。加载函数是 _setup 函数,当获取属性时才会去加载。

LazySettings 继承自 LazyObject 类,它重写了 __getattr____setattr__ 方法,那么在调用 settings.INSTALLED_APPS 时,就会触发 __getattr__ 这个双下方法. 我们知道, 初始化的时候, settings对象就是一个empty空对象.这就会去调用加载函数_setup函数

ENVIRONMENT_VARIABLE = "DJANGO_SETTINGS_MODULE"
def _setup(self, name=None):
    settings_module = os.environ.get(ENVIRONMENT_VARIABLE)
    self._wrapped = Settings(settings_module)

第一句话, setting_module就是从环境变量中获取我们用户自定义的配置文件, 这在刚启动manage.py文件就已经定义好了. 接下来就去实例化一个Settings对象. 从这就可以得出结论通过settings对象的属性都是从_wrapped这个私有属性获取来的, 或者说是从Settings实例对象中获取来的.

继续跟进Settings类的源码.

# global_settings就是一个django内部的全局配置文件
from django.conf import global_settings
class Settings(object):
    def __init__(self, settings_module):
        # 这句话就是遍历全局配置, 将所有的属性添加到settings对象中
        for setting in dir(global_settings):
            # 这里也说明了为什么属性需要大写
            if setting.isupper():
                setattr(self, setting, getattr(global_settings, setting))

        # store the settings module in case someone later cares
        self.SETTINGS_MODULE = settings_module
       # 这里就是动态的将我们用户的自定义配置文件模块导入
        mod = importlib.import_module(self.SETTINGS_MODULE)
        self._explicit_settings = set()
        # 遍历用户自定义配置文件
        for setting in dir(mod):
            # 如果我们配置的属性不是大写, 就会无效
            if setting.isupper():
                # 获取用户的配置属性
                setting_value = getattr(mod, setting)
                # 将我们配置的属性添加到settings配置文件中, 或者覆盖掉
                # Django默认的配置属性.
                setattr(self, setting, setting_value)
                self._explicit_settings.add(setting)

到了这, 开头的问题也就解决了. 来一句话总结, 就是Django先加载自己的配置文件, 然后再加载用户的配置文件覆盖掉默认的属性, 保存到一个settings延时加载的对象中. 配置文件大写的原因也只是因为源码只处理全大写的属性而已.

参考

  1. http://www.hongweipeng.com/index.php/archives/1370/
  2. https://blog.csdn.net/qq_24551305/article/details/96486835

原文地址:https://www.cnblogs.com/yscl/p/11614807.html

时间: 2024-11-05 20:33:31

Django的settings文件部分源码分析的相关文章

Django——基于类的视图源码分析 二

源码分析 抽象类和常用视图(base.py) 这个文件包含视图的顶级抽象类(View),基于模板的工具类(TemplateResponseMixin),模板视图(TemplateView)和重定向视图(RedirectView). View及View的执行顺序 View是所有基于类的视图的基类.仅实现了一些基本的方法和必要的检查工作.其中最重要的是dispatch方法.再次方法中,根据HTTP请求 中的method参数,调用相应的同名处理函数.这里留下了一个口子,后续的类需要根据自己的情况来填补

Django REST framework —— 权限组件源码分析

在上一篇文章中我们已经分析了认证组件源码,我们再来看看权限组件的源码,权限组件相对容易,因为只需要返回True 和False即可 代码 1 class ShoppingCarView(ViewSetMixin, APIView): 2 permission_classes = [MyPermission, ] 3 def list(self,request, *args, **kwargs): 4 """ 5 查看购物车信息 6 :param args: 7 :param k

Django Signals 从实践到源码分析(转)

原文:http://foofish.net/blog/66/django-signals 当某个事件发生的时候,signal(信号)允许senders(发送者)用来通知receivers(接收者),通知receivers干嘛?你想要recivers干嘛就可以干嘛.这在多处代码 对同一个事件感兴趣的时候就有用武之地了. 比如:Django提供了一个built-in signal,叫django.core.signals.request_finished,这个signal会在一个 HTTP请求完成后

Django rest framework 权限操作(源码分析二)

知识回顾 这一篇是基于上一篇写的,上一篇谢了认证的具体流程,看懂了上一篇这一篇才能看懂, 当用户访问是 首先执行dispatch函数,当执行当第二部时: #2.处理版本信息 处理认证信息 处理权限信息 对用户的访问频率进行限制 self.initial(request, *args, **kwargs) 进入到initial方法: def initial(self, request, *args, **kwargs): """ Runs anything that needs

Django——基于类的视图源码分析 一

基于类的视图(Class-based view)是Django 1.3引入的新的视图编写方式,用于取代以前基于函数(Function-based)方式. 借助于OO和Python中方便的多重继承特性,基于类的视图可以提供更好的抽象与复用能力. 新的通用视图将更加优雅. Django的文档较为丰富,但在实际开发中往往仍显得不够,很多时候还是需要深入到源代码当中一探究竟.为此,仔细整理了一下基于类的视图的实现方式.期望对以后的开发能够提供更加清晰.直接的参考. 说明: Django大量应用了多重继承

MapReduce(十五): 从HDFS读取文件的源码分析

以Map任务读取文本数据为例: 1)   LineRecordReader负责对文件分割的定位,以及对读取每一行内容的封装供用户Map任务使用.每次在定位在文件中不为0的位置时,多读取一行,因为前一个处理该位置之前的数据时,会完整把该一行已经读取并处理. 2)   LineReader负责对所要访问文件输入流的数据进行每一行读取,只实现对每一行读取的逻辑. 3)   DFSDataInputStream封装了DFSInputStream的实现,直接调用DFSInputStream接口完成. 4)

Django——基于类的视图源码分析 三

列表类通用视图(list.py) 此文件包含用于显示数据列表常用的类和工具类.不仅可以方便的用于显示基于模型(Model)的数据列表,也可以用于显示自定义数据列表. 此图中绿色部分属于base.py,引入此图中是为了说明他们之间的关系 MultipleObjectMixin 最主要的核心工具类,主要的算法和接口全部都在这个工具类中实现. 属性 allow_empty 默认值True.表示没有数据时显示空列表:否则将会产生一个404错误. queryset 产生数据的queryset实例或"类qu

django的restformework模块的源码分析

我们从路由函数开始分析 在我们自己定义的类中没有as_view方法的函数,所以肯定是继承了AIPView,那我们就去看下 view = super(APIView, cls).as_view(**initkwargs) 其中这句代码表示,最后它执行的是父类中的as_view方法,APIView类继承了原View类,所以查看View类中的as_view方法 由于APIView类中有自己的dispatch方法,所以是执行自己类中的dispatch 点进大写的Request()可以看到封装后的requ

Django中的as_view方法源码分析

django的类视图拥有自动查找指定方法的功能,通过调用as_views()方法实现. 在探讨这个问题之前,先引入一段代码举个例子方便理解: 一般请求的判断方法: def View(request,*args,**kwargs): if request.method.lower() == 'get': do_something() if request.method.lower() == 'post': do_something() 编写自定义的视图类,前提必须要继承基类View,然后使用Vie