werkzeug

一 .Flask初步使用 1.Flask简介 Flask是一个基于Python开发并且依赖jinja2模板和Werkzeug WSGI服务的一个微型框架，对于Werkzeug本质是Socket服务端，其用于接收http请求并对请求进行预处理，然后触发Flask框架，开发人员基于Flask框架提供的功能对请求进行相应的处理，并返回给用户，如果要返回给用户复杂的内容时，需要借助jinja2模板来实现对模板的处理，即：将模板和数据进行渲染，将渲染后的字符串返回给用户浏览器。 werkzeug简介 Werkzeug是一个WSGI工具包，他可以作为一个Web框架的底层库。这里稍微说一下， werkzeug 不是一个web服务器，也不是一个web框架，而是一个工具包，官方的介绍说是一个 WSGI 工具包，它可以作为一个 Web 框架的底层库，因为它封装好了很多 Web 框架的东西，例如 Request，Response 等等 flask 特点 1. 短小精悍 可扩展性强 的一个web框架 2. 上下文管理机制 3. 依赖wsgi :werkzurg 2. werkzurg学习(注意下载flask就带这个模块 了解) 示例1:from werkzeug.wrappers import Request, Response from werkzeug.serving import run

https://www.cnblogs.com/liuweida/p/11717683.html 来源： https://www.cnblogs.com/s686zhou/p/12199356.html

什么是 Local？ wsgi 每次请求，会把过程进行抽离无状态话，过程数据存储在本次请求的全局变量中，使用到了Local. Local 作为每次请求的全局命令空间，属于每次请求的私有 LocalStack 与 Local 相似，在 Local 基础之上使用堆栈方式进行操作，管理 LocalProxy 代理类，代理 Local 或 LocalStack 实例 为什么使用 Local？ 　为什么使用自定义 Local，而不是 threading.local。这是由内核决定的 web 应用在启动之后，是一单线+协成程启动的话，会污染全局变量，无法区分， 使用多线程+协成无法保证，派发请求的工作协程，无法保证同时工作时且分别位于多个线程内，彼此互不影响 所以： werkzeug 给出了自己的解决方案：Local 和 LocalStack 为什么使用 LocalProxy？ 　　那么问题来了：请求的上下文的私有变量存储在 Local 和 LocalStack 中，那在多任务时，每次调用 from flask import request, g, session ， 如何保证获取正确的上下文，而不发生混乱？ 在 flask.globals.py 中 #Python学习交流群797877325 免费获取系统学习教程 def _lookup_req_object ( name ) : top =

什么是 Local wsgi 每次请求，会把过程进行抽离无状态话，过程数据存储在本次请求的全局变量中，使用到了Local. Local 作为每次请求的全局命令空间，属于每次请求的私有 LocalStack 与 Local 相似，在 Local 基础之上使用堆栈方式进行操作，管理 LocalProxy 代理类，代理 Local 或 LocalStack 实例 为什么使用 Local 　　为什么使用自定义 Local，而不是 threading.local。这是由内核决定的 　　　　1. web 应用在启动之后，是一单线+协成程启动的话，会污染全局变量，无法区分， 　　　　2. 使用多线程+协成无法保证，派发请求的工作协程，无法保证同时工作时且分别位于多个线程内，彼此互不影响 所以： werkzeug 给出了自己的解决方案：Local 和 LocalStack 为什么使用 LocalProxy 　　那么问题来了：请求的上下文的私有变量存储在 Local 和 LocalStack 中，那在多任务时，每次调用 from flask import request, g, session ， 如何保证获取正确的上下文，而不发生混乱？ 在 flask.globals.py 中 def _lookup_req_object(name): top = _request_ctx_stack.top