from flask import Flask """ 1 实例化对象 app """ app = Flask(__name__) """ 2 设置路由 将路由关系放在 app.url_map = {} 中 """ @app.route("/index") def index(): return "index" if —__name__ == "__main__": """ 3 启动socket服务端 """ app.run() """ 4 用户请求到来就会执行 __call__ 方法 """
# 启动入口简约版代码 from werkzeug.wrappers import Response from werkzeug.serving import run_simple class Flask(object): def __call__(self,environ, start_response): response = Response('hello') return response(environ, start_response) def run(self): run_simple('127.0.0.1', 8000, self)
run_simple(host,port,self,**options)
会对第三个传入的参数加()进行执行
第三个参数若是是app对象就执行其 __call__ 方法python
def __call__(self,environ, start_response): # environ 请求相关的全部数据 第一手的数据,由wsgi进行的初步封装 # start_response 用于设置响应相关数据 return wsgi_app(environ,start_response)
call 返回的是 wsgi_app 的执行结果web
wsgi_app 里面作的事情就不少了。面试
咱们一步一步来看redis
首先把请求相关的全部数据都 封装了到 一个 ctx 对象sql
并且经过 __init__ 能够看到 封装了 request 以及建立了一个 空的 session 数据库
获得了 ctx 对象django
建立ctx.request 以及 ctx.session = None flask
来看下 push 都作了什么cookie
封了一个top,这是啥不知道,要继续看是个 LocalStack 对象session
class LocalStack(object): """This class works similar to a :class:`Local` but keeps a stack of objects instead. This is best explained with an example:: >>> ls = LocalStack() >>> ls.push(42) >>> ls.top 42 >>> ls.push(23) >>> ls.top 23 >>> ls.pop() 23 >>> ls.top 42 They can be force released by using a :class:`LocalManager` or with the :func:`release_local` function but the correct way is to pop the item from the stack after using. When the stack is empty it will no longer be bound to the current context (and as such released). By calling the stack without arguments it returns a proxy that resolves to the topmost item on the stack. .. versionadded:: 0.6.1 """ def __init__(self): self._local = Local() def __release_local__(self): self._local.__release_local__() def _get__ident_func__(self): return self._local.__ident_func__ def _set__ident_func__(self, value): object.__setattr__(self._local, '__ident_func__', value) __ident_func__ = property(_get__ident_func__, _set__ident_func__) del _get__ident_func__, _set__ident_func__ def __call__(self): def _lookup(): rv = self.top if rv is None: raise RuntimeError('object unbound') return rv return LocalProxy(_lookup) def push(self, obj): """Pushes a new item to the stack""" rv = getattr(self._local, 'stack', None) if rv is None: self._local.stack = rv = [] rv.append(obj) return rv def pop(self): """Removes the topmost item from the stack, will return the old value or `None` if the stack was already empty. """ stack = getattr(self._local, 'stack', None) if stack is None: return None elif len(stack) == 1: release_local(self._local) return stack[-1] else: return stack.pop() @property def top(self): """The topmost item on the stack. If the stack is empty, `None` is returned. """ try: return self._local.stack[-1] except (AttributeError, IndexError): return None
这个 LocalStack 对象是什么咱们也仍是不知道,还需须要继续看,发现实际上是个 Local 对象
看到Local 到这里发现应该是看到底了,这样稍微看下 local 对象就是在 __storage__ 里面存了个数据结构
这个数据结构是这样的,
__storage__ = { 线程/协程id:{} 线程/协程id:{} 线程/协程id:{} }
class Local(object): __slots__ = ('__storage__', '__ident_func__') def __init__(self): object.__setattr__(self, '__storage__', {}) object.__setattr__(self, '__ident_func__', get_ident) def __iter__(self): return iter(self.__storage__.items()) def __call__(self, proxy): """Create a proxy for a name.""" return LocalProxy(self, proxy) def __release_local__(self): self.__storage__.pop(self.__ident_func__(), None) def __getattr__(self, name): try: return self.__storage__[self.__ident_func__()][name] except KeyError: raise AttributeError(name) def __setattr__(self, name, value): ident = self.__ident_func__() storage = self.__storage__ try: storage[ident][name] = value except KeyError: storage[ident] = {name: value} def __delattr__(self, name): try: del self.__storage__[self.__ident_func__()][name] except KeyError: raise AttributeError(name)
而后咱们在回头看下 LocalStark 是干吗的, 原来这货是帮助维护这个数据结构的,
会把 Local 的数据进一步维护成这样
__storage__ = { 线程/协程id:{stack:[ctx]} # 维护成一个栈 线程/协程id:{stack:[ctx]} 线程/协程id:{stack:[ctx]} 线程/协程id:{stack:[ctx]} } # 都是经过 Localstack 来操做 local 里面的数据结构
并且 LocalStark 里面还有一系列的操做方法,因而可知 LocalStark 应该就是专门操做 Local 对象数据的
ok,走到头了回去接着往下走
有封装了一个 app_ctx ,其实刚刚看 top 的时候就已经发现了 下面有个 app_ctx_stack 了
可见其实封装了两个 LocalStark 对象,分别是 请求相关的 以及 app相关的
而后继续往下走,这里分装了 app_ctx 是 AppContext 的 对象,
里面封装了,app 和 g
看到了这里
这里就是对 session 的操做了。以前的 session 一直是 空,这里进行真正的赋值。
可见 session 的赋值是经过配置文件的 配置名字 取到 session ,而后解密反序列化生成字典从新赋值 ctx.session 的具体操做实现
至此,push() 的代码看完了。
分装了 两个 ctx :
- 请求上下文(ctx=RequestContext()):request/session
- App上下文(app_ctx=AppContext()): app/g
这两 ctx 都分别保存了两个 LocalStark 以及 两个 Local
以及 赋值了 ctx.session
这里就不详细看了。
大概作了两件事,执行了处理视图函数,以及一系列善后工做,
视图函数执行完毕后,一次请求结束,把请求的 ctx 对象弹出,
在看过了 总体的 Flask 的一次请求的流程以后,
咱们再来分析上下文管理 ,直接看到这个比较重点的地方把
两个 LocalStack 对象,以及重要的 request,session 的产生的地方。
这里使用了 LocalProxy用于代理Local对象和LocalStack对象,以及偏函数
两个Local: local1 = {} local2 = {} 两个LocalStack: _request_ctx_stack _app_ctx_stack
对数据进行封装: ctx = RequestContext(request,session) app_ctx = AppContext(app,g)
保存数据 将包含了(app,g)数据的app_ctx对象,利用 _app_ctx_stack(LocalStack())将app_ctx添加到Local中 storage = { 1231:{stack:[app_ctx(app,g),]} }
将包含了request,session数据的ctx对象,利用_request_ctx_stack(LocalStack()),将ctx添加到Local中 storage = { 1231:{stack:[ctx(request,session),]} }
@app.route('/index') def index(): # 去请求上下文中获取值 _request_ctx_stack request.method session['xxx'] # 去app上下文中获取值:_app_ctx_stack print(current_app) print(g) return "Index"
方式一:直接找LocalStack获取 from flask.globals import _request_ctx_stack print(_request_ctx_stack.top.request.method) 方式二:经过代理LocalProx获取 from flask import Flask,request print(request.method)
_app_ctx_stack.pop()
_request_ctx_stack.pop()
问题一:flask和django的区别: 对于django来讲,内部组件特别多,自身功能强大,有点大而全,而flask,内置组件不多,可是它的第三方组件不少,扩展性强,有点短小精悍,而它们之间也有类似之处, 由于它们两个框架都没有写sockte,都是基于wsgi协议作的,在此以外,flask框架中的上下文管理较为耀眼。 相同点:它们两个框架都没有写sockte,都是基于wsgi协议作的 请求相关数据传递的方式不一样:django:经过传递request参数取值 flask:见问题二 组件不一样:django组件多 flask组件少,第三方组件丰富 问题1.1: flask上下文管理: 简单来讲,falsk上下文管理能够分为三个阶段: 1、请求进来时,将请求相关的数据放入上下问管理中 2、在视图函数中,要去上下文管理中取值 3、请求响应,要将上下文管理中的数据清除 详细点来讲: 1、请求刚进来,将request,session封装在RequestContext类中,app,g封装在AppContext类中,并经过LocalStack将requestcontext和appcontext放入Local类中 二、视图函数中,经过localproxy--->偏函数--->localstack--->local取值 3、请求相应时,先执行save.session()再各自执行pop(),将local中的数据清除 问题1.2 flask第三方组件 flask: -flask-session 默认放入cookie,能够放入redis -flask-redis -flask-migrate -flask-script -blinker 信号 公共: DBUtils 数据库链接池 wtforms 表单验证+生成HTML标签 sqlalchemy 自定义:Auth 参考falsk-login 问题二:Flask中的session是何时建立,何时销毁的? 当请求进来时,会将requset和session封装为一个RequestContext对象,经过LocalStack将RequestContext放入到Local对象中,由于 请求第一次来session是空值,因此执行open_session,给session(uuid4())赋值,再经过视图函数处理,请求响应时执行save.session,将签名session写入cookie中,再讲Local中的数值pop掉。 问题三:flask中一共有几个LocalStack和Local对象 两个LocalStack,两个Local request、session共同用一个LocalStack和Local g、app共同用一个Localstack和Local 问题四: 为何把请求放到RequestContext中: 由于request和session都是在视图中操做频繁的数据,也是用户请求须要用的数据,将request和session封装在RequestContext中top,pop一次就能够完成,而单独不封装在一块儿就会屡次操做, ctx = RequestContext(request,session) 问题五:local做用 -保存 请求上下文对象和app上下文对象 -localstack的源码与threading.local(线程处理)做用类似,不一样之处是Local是经过greenlet(协程)获取惟一标识,粒度更细 问题六:Localstack做用 2、将local对象中的数据维护成一个栈【ctx,ctx】(先进后出) { “协程或线程的惟一标识”: { stack:[ctx,ctx,ctx,] } } 为何维护成一个栈? 当是web应用时:不论是单线程仍是多线程,栈中只有一个数据 - 服务端单线程: { 111:{stack: [ctx, ]} } - 服务端多线程: { 111:{stack: [ctx, ]} 112:{stack: [ctx, ]} } 离线脚本:能够在栈中放入多个数据 with app01.app_context(): print(current_app) with app02.app_context(): print(current_app) print(current_app) 问题七:什么是g? g 至关于一次请求的全局变量,当请求进来时将g和current_app封装为一个APPContext类,在经过LocalStack将Appcontext放入Local中,取值时经过偏函数,LocalStack、loca l中取值,响应时将local中的g数据删除: 问题八:怎么获取Session/g/current_app/request 经过 、偏函数(lookup_req_object)、Localstack、Local取值 问题九: 技术点: - 反射 (LocalProxy()) - 面向对象,封装:RequestContext - 线程(threading.local) - 笔试:本身写一个类+列表 实现栈。(LocalStack) 问题十:python基本哪些内容比较重要: 1、反射 -CBV -django配置文件 -wtforms中的Form()示例化中 将"_fields中的数据封装到From类中" 2、装饰器 (迭代器,生成器) -flask:路由、装饰器 -认证 -csrf 3、面向对象 -继承、封装、多态(简单描述) -双下划线: __mro__ wtform中 FormMeta中继承类的优先级 __dict__ __new__ ,实例化可是没有给当前对象 wtforms,字段实例化时返回:不是StringField,而是UnboundField rest frawork many=Turn 中的序列化 __call__ flask 请求的入口app.run() 字段生成标签时:字段.__str__ => 字段.__call__ => 插件.__call__ __iter__ 循环对象是,自定义__iter__ wtforms中BaseForm中循环全部字段时定义了__iter__ metaclass - 做用:用于指定当前类使用哪一个类来建立 - 场景:在类建立以前定制操做 示例:wtforms中,对字段进行排序。