django template
django_template 知识点总结
模板有三个知识点
变量
标签
过滤器
变量
- 变量的形式是:, 当模板引擎碰到变量的时候,引擎使用变量的值代替变量。
- 使用dot(.)能够访问变量的属性
当模板引擎碰到dot的时候,查找的顺序是什么样子呢?
- 字典查找,例如:foo[“var1”]
- 属性查找,例如:foo.bar
- 方法查找,例如:foo.bar()
- list-index查找,例如:foo[bar]
注意:方法查找比一般的查找要复杂一些
(1)如果调用方法期间,方法抛出一个异常,那么异常将会产生,除非异常对象带有一个属性silent_variable_failure,
如果这个值是True,那么将会返回一个空字串。
(2)方法调用仅仅对那些没有参数的方法才会生效
(3)一些方法会产生副作用,所以系统允许方法设置一个属性alters_data,如果值为True,那么将不能够调用
其设置方法是:
1 | def sensitive_function(self): |
- 如果模板中使用的某个变量不存在,那么模板系统将使用setting.py中 变量TEMPLATE_STRING_IF_INVALID的值进行替代,在默认情况下,该变量的值是’’。
multiprocessing
进程 线程 协程
python网络编程的两大必学模块socket和socketserver,其中的socketserver是一个支持IO多路复用和多线程、多进程的模块。
一般我们在socketserver服务端代码中都会写这么一句:
server = socketserver.ThreadingTCPServer(settings.IP_PORT, MyServer)
ThreadingTCPServer这个类是一个支持多线程和TCP协议的socketserver,它的继承关系是这样的:
class ThreadingTCPServer(ThreadingMixIn, TCPServer):
pass
右边的TCPServer实际上是它主要的功能父类,而左边的ThreadingMixIn则是实现了多线程的类,它自己本身则没有任何代码。
MixIn在python的类命名中,很常见,一般被称为“混入”,戏称“乱入”,通常为了某种重要功能被子类继承。
1 | class ThreadingMixIn: |
在ThreadingMixIn类中,其实就定义了一个属性,两个方法。在process_request方法中实际调用的正是python内置的多线程模块threading。这个模块是python中所有多线程的基础,socketserver本质上也是利用了这个模块。
1. thread
线程,有时被称为轻量级进程(Lightweight Process,LWP),是程序执行流的最小单元。一个标准的线程由线程ID,当前指令指针(PC),寄存器集合和堆栈组成。另外,线程是进程中的一个实体,是被系统独立调度和分派的基本单位,线程自己不独立拥有系统资源,但它可与同属一个进程的其它线程共享该进程所拥有的全部资源。一个线程可以创建和撤消另一个线程,同一进程中的多个线程之间可以并发执行。由于线程之间的相互制约,致使线程在运行中呈现出间断性。线程也有就绪、阻塞和运行三种基本状态。就绪状态是指线程具备运行的所有条件,逻辑上可以运行,在等待处理机;运行状态是指线程占有处理机正在运行;阻塞状态是指线程在等待一个事件(如某个信号量),逻辑上不可执行。每一个应用程序都至少有一个进程和一个线程。线程是程序中一个单一的顺序控制流程。在单个程序中同时运行多个线程完成不同的被划分成一块一块的工作,称为多线程。
以上那一段,可以不用看!举个例子,厂家要生产某个产品,在它的生产基地建设了很多厂房,每个厂房内又有多条流水生产线。所有厂房配合将整个产品生产出来,某个厂房内的所有流水线将这个厂房负责的产品部分生产出来。每个厂房拥有自己的材料库,厂房内的生产线共享这些材料。而每一个厂家要实现生产必须拥有至少一个厂房一条生产线。那么这个厂家就是某个应用程序;每个厂房就是一个进程;每条生产线都是一个线程。
python 主要是 threading 库
普通的多线程
1 | import threading |
上述代码创建了10个“前台”线程,然后控制器就交给了CPU,CPU根据指定算法进行调度,分片执行指令。
下面是Thread类的主要方法:
- start 线程准备就绪,等待CPU调度
- setName 为线程设置名称
- getName 获取线程名称
- setDaemon 设置为后台线程或前台线程(默认是False,前台线程)
如果是后台线程,主线程执行过程中,后台线程也在进行,主线程执行完毕后,后台线程不论成功与否,均停止。如果是前台线程,主线程执行过程中,前台线程也在进行,主线程执行完毕后,等待前台线程也执行完成后,程序停止。 - join 该方法非常重要。它的存在是告诉主线程,必须在这个位置等待子线程执行完毕后,才继续进行主线程的后面的代码。但是当setDaemon为True时,join方法是无效的。
- run 线程被cpu调度后自动执行线程对象的run方法
python的GIL,也就是全局解释器锁。在编程语言的世界,python因为GIL的问题广受诟病,因为它在解释器的层面限制了程序在同一时间只有一个线程被CPU实际执行,而不管你的程序里实际开了多少条线程。所以我们经常能发现,python中的多线程编程有时候效率还不如单线程,就是因为这个原因。那么,对于这个GIL,一些普遍的问题如下:
- 为什么有 GIL
作为解释型语言,Python的解释器必须做到既安全又高效。我们都知道多线程编程会遇到的问题。解释器要留意的是避免在不同的线程操作内部共享的数据。同时它还要保证在管理用户线程时总是有最大化的计算资源。那么,不同线程同时访问时,数据的保护机制是怎样的呢?答案是解释器全局锁GIL。GIL对诸如当前线程状态和为垃圾回收而用的堆分配对象这样的东西的访问提供着保护。
- 为什么不能去掉
首先,在早期的python解释器依赖较多的全局状态,传承下来,使得想要移除当今的GIL变得更加困难。其次,对于程序员而言,仅仅是想要理解它的实现就需要对操作系统设计、多线程编程、C语言、解释器设计和CPython解释器的实现有着非常彻底的理解。
在1999年,针对Python1.5,一个“freethreading”补丁已经尝试移除GIL,用细粒度的锁来代替。然而,GIL的移除给单线程程序的执行速度带来了一定的负面影响。当用单线程执行时,速度大约降低了40%。虽然使用两个线程时在速度上得到了提高,但这个提高并没有随着核数的增加而线性增长。因此这个补丁没有被采纳。
另外,在python的不同解释器实现中,如PyPy就移除了GIL,其执行速度更快(不单单是去除GIL的原因)。然而,我们通常使用的CPython占有着统治地位的使用量,所以,你懂的。
在Python 3.2中实现了一个新的GIL,并且带着一些积极的结果。这是自1992年以来,GIL的一次最主要改变。旧的GIL通过对Python指令进行计数来确定何时放弃GIL。在新的GIL实现中,用一个固定的超时时间来指示当前的线程以放弃这个锁。在当前线程保持这个锁,且当第二个线程请求这个锁的时候,当前线程就会在5ms后被强制释放掉这个锁(这就是说,当前线程每5ms就要检查其是否需要释放这个锁)。当任务是可行的时候,这会使得线程间的切换更加可预测。
- 实际建议
建议在IO密集型任务中使用多线程,
在CPU密集型任务中使用多进程。
深入研究python的协程机制,你会有惊喜的。
通常而言,队列是一种先进先出的数据结构,与之对应的是堆栈这种后进先出的结构。但是在python中,它内置了一个queue模块,它不但提供普通的队列,还提供一些特殊的队列。具体如下:
- queue.Queue :先进先出队列
- queue.LifoQueue :后进先出队列
- queue.PriorityQueue :优先级队列
- queue.deque :双向队列
生产者 消费者
生产者消费者模式是通过一个容器来解决生产者和消费者的强耦合问题。生产者和消费者彼此之间不直接通讯,而通过阻塞队列来进行通讯,所以生产者生产完数据之后不用等待消费者处理,直接扔给阻塞队列,消费者不找生产者要数据,而是直接从阻塞队列里取,阻塞队列就相当于一个缓冲区,平衡了生产者和消费者的处理能力。
这个阻塞队列就是用来给生产者和消费者解耦的。纵观大多数设计模式,都会找一个第三者出来进行解耦,如工厂模式的第三者是工厂类,模板模式的第三者是模板类。在学习一些设计模式的过程中,如果先找到这个模式的第三者,能帮助我们快速熟悉一个设计模式。
1 | #!/usr/bin/env python |
线程池
在使用多线程处理任务时也不是线程越多越好,由于在切换线程的时候,需要切换上下文环境,依然会造成cpu的大量开销。为解决这个问题,线程池的概念被提出来了。预先创建好一个较为优化的数量的线程,让过来的任务立刻能够使用,就形成了线程池。在python中,没有内置的较好的线程池模块,需要自己实现或使用第三方模块。下面是一个简单的线程池:
1 | #!/usr/bin/env python |
1 | #!/usr/bin/env python |
2. process
在python中multiprocess模块提供了Process类,实现进程相关的功能。但是,由于它是基于fork机制的,因此不被windows平台支持。想要在windows中运行,必须使用if __name == ‘\main__:的方式,显然这只能用于调试和学习,不能用于实际环境。
(PS:在这里我必须吐槽一下python的包、模块和类的组织结构。在multiprocess中你既可以import大写的Process,也可以import小写的process,这两者是完全不同的东西。这种情况在python中很多,新手容易傻傻分不清。)
想要进程之间进行资源共享可以使用queues/Array/Manager这三个multiprocess模块提供的类。
1 | from multiprocessing import Process |
1 | from multiprocessing import Process,Manager |
1 | import multiprocessing |
这里就有点类似上面的队列了。从运行结果里,你还能发现数据共享中存在的脏数据问题。另外,比较悲催的是multiprocessing里还有一个Queue,一样能实现这个功能。
3. coroutine
线程和进程的操作是由程序触发系统接口,最后的执行者是系统,它本质上是操作系统提供的功能。而协程的操作则是程序员指定的,在python中通过yield,人为的实现并发处理。
协程存在的意义:对于多线程应用,CPU通过切片的方式来切换线程间的执行,线程切换时需要耗时。协程,则只使用一个线程,分解一个线程成为多个“微线程”,在一个线程中规定某个代码块的执行顺序。
协程的适用场景:当程序中存在大量不需要CPU的操作时(IO)。
在不需要自己“造轮子”的年代,同样有第三方模块为我们提供了高效的协程,这里介绍一下greenlet和gevent。本质上,gevent是对greenlet的高级封装,因此一般用它就行,这是一个相当高效的模块。
1 | from gevent import monkey; monkey.patch_all() |
how-to-deploy-django
django 部署的关键点
- 安全秘匙 secret key 从环境变量中加载或者是从文件中进行读取
- 生产环境不能启动debug模式
- allow_hosts
- 缓存
- 数据库
- email设置
- 伺服静态文件
- 媒体文件是用户上传的,是不能信任的
- HTTPS
- csrf
- session
- 性能优化等
- 日志的配置
how-to-understand-unittest
关于测试
有段时间被领导叫过去写单元测试。
这段时间决定对此段经历做一些总结。
单元测试是一种软件测试过程,测试的是软件应用程序的独立单元,确保能做预期中的事情。
分为不同的层级,可以测试单个方法,看它能否返回正确的值以及能否处理正确的数据,
也可以测试整个方法组件,确保一系列用户输入能得到所需的结果。
单元测试背后,有四个基本的概念:
测试固件 fixture 执行测试所需要的设置。包含数据库、示例数据集合服务器搭建。可能还包括测试完毕之后执行的清理操作。
用例 case 测试的基本单元。检查指定的输入能否得到预期的结果。
- 组件 suit 一系列测试用例或者其他测试组件,作为一个整体执行
- 运行程序 runner 负责执行测试并把结果反馈給用户的软件程序。
自动化测试
优点
节省时间
避免出问题
看起来专业
增进团队协作
将测试代码封装到一个类中,并且增加断言。
django的单元测试
会在app应用中查找测试
找到 testcase 的一个子类
为测试创建一个特殊的数据库
查找以test开头的测试方法
报告失败的测试
Django 为 编写测试提供了一些便利的工具
测试客户端
伪装成一个web浏览器
模拟对URL 的 GET POST 请求
跟踪重定向
测试指定的请求由指定的django 模板渲染,而且模板上下文包含特定的值
客户端的目的不是取代 selenium 或者是其他操作浏览器的框架
用于确认是否渲染了正确的模板,而且为模板传入了正确的上下文数据
TestCase 有一些扩展
Simple的
Transaction的
等等…