Python中的魔法方法深入理解
接触Python也有一段时间了,Python相关的框架和模块也接触了不少,希望把自己接触到的自己 觉得比较好的设计和实现分享给大家,于是取了一个“Charming Python”的小标,算是给自己开了一个头吧, 希望大家多多批评指正。 :)
from flask import request
Flask 是一个人气非常高的Python Web框架,笔者也拿它写过一些大大小小的项目,Flask 有一个特性我非常的喜欢,就是无论在什么地方,如果你想要获取当前的request对象,只要 简单的:
from flask import request
# 从当前request获取内容
request.args
request.forms
request.cookies
... ...
非常简单好记,用起来也非常的友好。不过,简单的背后藏的实现可就稍微有一些复杂了。 跟随我的文章来看看其中的奥秘吧!
两个疑问?
在我们往下看之前,我们先提出两个疑问:
疑问一 : request ,看上去只像是一个静态的类实例,我们为什么可以直接使用request.args 这样的表达式来获取当前request的args属性,而不用使用比如:
from flask import get_request
# 获取当前request
request = get_request()
get_request().args
这样的方式呢?flask是怎么把request对应到当前的请求对象的呢?
疑问二 : 在真正的生产环境中,同一个工作进程下面可能有很多个线程(又或者是协程), 就像我刚刚所说的,request这个类实例是怎么在这样的环境下正常工作的呢?
要知道其中的秘密,我们只能从flask的源码开始看了。
源码,源码,还是源码
首先我们打开flask的源码,从最开始的__init__.py来看看request是怎么出来的:
# File: flask/__init__.py
from .globals import current_app, g, request, session, _request_ctx_stack
# File: flask/globals.py
from functools import partial
from werkzeug.local import LocalStack, LocalProxy
def _lookup_req_object(name):
top = _request_ctx_stack.top
if top is None:
raise RuntimeError('working outside of request context')
return getattr(top, name)
# context locals
_request_ctx_stack = LocalStack()
request = LocalProxy(partial(_lookup_req_object, 'request'))
我们可以看到flask的request是从globals.py引入的,而这里的定义request的代码为 request = LocalProxy(partial(_lookup_req_object, 'request')) , 如果有不了解 partial是什么东西的同学需要先补下课,首先需要了解一下 partial 。
不过我们可以简单的理解为 partial(func, 'request') 就是使用 'request' 作为func的第一个默认参数来产生另外一个function。
所以, partial(_lookup_req_object, 'request') 我们可以理解为:
生成一个callable的function,这个function主要是从 _request_ctx_stack 这个LocalStack对象获取堆栈顶部的第一个RequestContext对象,然后返回这个对象的request属性。
这个werkzeug下的LocalProxy引起了我们的注意,让我们来看看它是什么吧:
@implements_bool
class LocalProxy(object):
"""Acts as a proxy for a werkzeug local. Forwards all operations to
a proxied object. The only operations not supported for forwarding
are right handed operands and any kind of assignment.
... ...
看前几句介绍就能知道它主要是做什么的了,顾名思义,LocalProxy主要是就一个Proxy, 一个为werkzeug的Local对象服务的代理。他把所以作用到自己的操作全部“转发”到 它所代理的对象上去。
那么,这个Proxy通过Python是怎么实现的呢?答案就在源码里:
# 为了方便说明,我对代码进行了一些删减和改动
@implements_bool
class LocalProxy(object):
__slots__ = ('__local', '__dict__', '__name__')
def __init__(self, local, name=None):
# 这里有一个点需要注意一下,通过了__setattr__方法,self的
# "_LocalProxy__local" 属性被设置成了local,你可能会好奇
# 这个属性名称为什么这么奇怪,其实这是因为Python不支持真正的
# Private member,具体可以参见官方文档:
# http://docs.python.org/2/tutorial/classes.html#private-variables-and-class-local-references
# 在这里你只要把它当做 self.__local = local 就可以了 :)
object.__setattr__(self, '_LocalProxy__local', local)
object.__setattr__(self, '__name__', name)
def _get_current_object(self):
"""
获取当前被代理的真正对象,一般情况下不会主动调用这个方法,除非你因为
某些性能原因需要获取做这个被代理的真正对象,或者你需要把它用来另外的
地方。
"""
# 这里主要是判断代理的对象是不是一个werkzeug的Local对象,在我们分析request
# 的过程中,不会用到这块逻辑。
if not hasattr(self.__local, '__release_local__'):
# 从LocalProxy(partial(_lookup_req_object, 'request'))看来
# 通过调用self.__local()方法,我们得到了 partial(_lookup_req_object, 'request')()
# 也就是 ``_request_ctx_stack.top.request``
return self.__local()
try:
return getattr(self.__local, self.__name__)
except AttributeError:
raise RuntimeError('no object bound to %s' % self.__name__)
# 接下来就是一大段一段的Python的魔法方法了,Local Proxy重载了(几乎)?所有Python
# 内建魔法方法,让所有的关于他自己的operations都指向到了_get_current_object()
# 所返回的对象,也就是真正的被代理对象。
... ...
__setattr__ = lambda x, n, v: setattr(x._get_current_object(), n, v)
__delattr__ = lambda x, n: delattr(x._get_current_object(), n)
__str__ = lambda x: str(x._get_current_object())
__lt__ = lambda x, o: x._get_current_object()
__le__ = lambda x, o: x._get_current_object()
__eq__ = lambda x, o: x._get_current_object() == o
__ne__ = lambda x, o: x._get_current_object() != o
__gt__ = lambda x, o: x._get_current_object() > o
__ge__ = lambda x, o: x._get_current_object() >= o
... ...
事情到了这里,我们在文章开头的第二个疑问就能够得到解答了,我们之所以不需要使用get_request() 这样的方法调用来获取当前的request对象,都是LocalProxy的功劳。
LocalProxy作为一个代理,通过自定义魔法方法。代理了我们对于request的所有操作, 使之指向到真正的request对象。
怎么样,现在知道了 request.args 不是它看上去那么简简单单的吧。
现在,让我们来看看第二个问题,在多线程的环境下,request是怎么正常工作的呢? 还是让我们回到globals.py吧:
from functools import partial
from werkzeug.local import LocalStack, LocalProxy
def _lookup_req_object(name):
top = _request_ctx_stack.top
if top is None:
raise RuntimeError('working outside of request context')
return getattr(top, name)
# context locals
_request_ctx_stack = LocalStack()
request = LocalProxy(partial(_lookup_req_object, 'request'))
问题的关键就在于这个 _request_ctx_stack 对象了,让我们找到LocalStack的源码:
class LocalStack(object):
def __init__(self):
# 其实LocalStack主要还是用到了另外一个Local类
# 它的一些关键的方法也被代理到了这个Local类上
# 相对于Local类来说,它多实现了一些和堆栈“Stack”相关方法,比如push、pop之类
# 所以,我们只要直接看Local代码就可以
self._local = Local()
... ...
@property
def top(self):
"""
返回堆栈顶部的对象
"""
try:
return self._local.stack[-1]
except (AttributeError, IndexError):
return None
# 所以,当我们调用_request_ctx_stack.top时,其实是调用了 _request_ctx_stack._local.stack[-1]
# 让我们来看看Local类是怎么实现的吧,不过在这之前我们得先看一下下面出现的get_ident方法
# 首先尝试着从greenlet导入getcurrent方法,这是因为如果flask跑在了像gevent这种容器下的时候
# 所以的请求都是以greenlet作为最小单位,而不是thread线程。
try:
from greenlet import getcurrent as get_ident
except ImportError:
try:
from thread import get_ident
except ImportError:
from _thread import get_ident
# 总之,这个get_ident方法将会返回当前的协程/线程ID,这对于每一个请求都是唯一的
class Local(object):
__slots__ = ('__storage__', '__ident_func__')
def __init__(self):
object.__setattr__(self, '__storage__', {})
object.__setattr__(self, '__ident_func__', get_ident)
... ...
# 问题的关键就在于Local类重载了__getattr__和__setattr__这两个魔法方法
def __getattr__(self, name):
try:
# 在这里我们返回调用了self.__ident_func__(),也就是当前的唯一ID
# 来作为__storage__的key
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}
... ...
# 重载了这两个魔法方法之后
# Local().some_value 不再是它看上去那么简单了:
# 首先我们先调用get_ident方法来获取当前运行的线程/协程ID
# 然后获取这个ID空间下的some_value属性,就像这样:
#
# Local().some_value -> Local()[current_thread_id()].some_value
#
# 设置属性的时候也是这个道理
通过这些分析,相信疑问二也得到了解决,通过使用了当前的线程/协程ID,加上重载一些魔法 方法,Flask实现了让不同工作线程都使用了自己的那一份stack对象。这样保证了request的正常 工作。
说到这里,这篇文章也差不多了。我们可以看到,为了使用者的方便,作为框架和工具的开发者 需要付出很多额外的工作,有时候,使用一些语言上的魔法是无法避免的,Python在这方面也有着 相当不错的支持。
我们所需要做到的就是,学习掌握好Python中那些魔法的部分,使用魔法来让自己的代码更简洁, 使用更方便。
但是要记住,魔法虽然炫,千万不要滥用哦。

热AI工具

Undresser.AI Undress
人工智能驱动的应用程序,用于创建逼真的裸体照片

AI Clothes Remover
用于从照片中去除衣服的在线人工智能工具。

Undress AI Tool
免费脱衣服图片

Clothoff.io
AI脱衣机

AI Hentai Generator
免费生成ai无尽的。

热门文章

热工具

记事本++7.3.1
好用且免费的代码编辑器

SublimeText3汉化版
中文版,非常好用

禅工作室 13.0.1
功能强大的PHP集成开发环境

Dreamweaver CS6
视觉化网页开发工具

SublimeText3 Mac版
神级代码编辑软件(SublimeText3)

热门话题

MySQL 有免费的社区版和收费的企业版。社区版可免费使用和修改,但支持有限,适合稳定性要求不高、技术能力强的应用。企业版提供全面商业支持,适合需要稳定可靠、高性能数据库且愿意为支持买单的应用。选择版本时考虑的因素包括应用关键性、预算和技术技能。没有完美的选项,只有最合适的方案,需根据具体情况谨慎选择。

文章介绍了MySQL数据库的上手操作。首先,需安装MySQL客户端,如MySQLWorkbench或命令行客户端。1.使用mysql-uroot-p命令连接服务器,并使用root账户密码登录;2.使用CREATEDATABASE创建数据库,USE选择数据库;3.使用CREATETABLE创建表,定义字段及数据类型;4.使用INSERTINTO插入数据,SELECT查询数据,UPDATE更新数据,DELETE删除数据。熟练掌握这些步骤,并学习处理常见问题和优化数据库性能,才能高效使用MySQL。

MySQL安装失败的原因主要有:1.权限问题,需以管理员身份运行或使用sudo命令;2.依赖项缺失,需安装相关开发包;3.端口冲突,需关闭占用3306端口的程序或修改配置文件;4.安装包损坏,需重新下载并验证完整性;5.环境变量配置错误,需根据操作系统正确配置环境变量。解决这些问题,仔细检查每个步骤,就能顺利安装MySQL。

MySQL下载文件损坏,咋整?哎,下载个MySQL都能遇到文件损坏,这年头真是不容易啊!这篇文章就来聊聊怎么解决这个问题,让大家少走弯路。读完之后,你不仅能修复损坏的MySQL安装包,还能对下载和安装过程有更深入的理解,避免以后再踩坑。先说说为啥下载文件会损坏这原因可多了去了,网络问题是罪魁祸首,下载过程中断、网络不稳定都可能导致文件损坏。还有就是下载源本身的问题,服务器文件本身就坏了,你下载下来当然也是坏的。另外,一些杀毒软件过度“热情”的扫描也可能造成文件损坏。诊断问题:确定文件是否真的损坏

MySQL 可在无需网络连接的情况下运行,进行基本的数据存储和管理。但是,对于与其他系统交互、远程访问或使用高级功能(如复制和集群)的情况,则需要网络连接。此外,安全措施(如防火墙)、性能优化(选择合适的网络连接)和数据备份对于连接到互联网的 MySQL 数据库至关重要。

MySQL数据库性能优化指南在资源密集型应用中,MySQL数据库扮演着至关重要的角色,负责管理海量事务。然而,随着应用规模的扩大,数据库性能瓶颈往往成为制约因素。本文将探讨一系列行之有效的MySQL性能优化策略,确保您的应用在高负载下依然保持高效响应。我们将结合实际案例,深入讲解索引、查询优化、数据库设计以及缓存等关键技术。1.数据库架构设计优化合理的数据库架构是MySQL性能优化的基石。以下是一些核心原则:选择合适的数据类型选择最小的、符合需求的数据类型,既能节省存储空间,又能提升数据处理速度

MySQL性能优化需从安装配置、索引及查询优化、监控与调优三个方面入手。1.安装后需根据服务器配置调整my.cnf文件,例如innodb_buffer_pool_size参数,并关闭query_cache_size;2.创建合适的索引,避免索引过多,并优化查询语句,例如使用EXPLAIN命令分析执行计划;3.利用MySQL自带监控工具(SHOWPROCESSLIST,SHOWSTATUS)监控数据库运行状况,定期备份和整理数据库。通过这些步骤,持续优化,才能提升MySQL数据库性能。

MySQL拒启动?别慌,咱来排查!很多朋友安装完MySQL后,发现服务死活启动不了,心里那个急啊!别急,这篇文章带你从容应对,揪出幕后黑手!读完后,你不仅能解决这个问题,还能提升对MySQL服务的理解,以及排查问题的思路,成为一名更强大的数据库管理员!MySQL服务启动失败,原因五花八门,从简单的配置错误到复杂的系统问题都有可能。咱们先从最常见的几个方面入手。基础知识:服务启动流程简述MySQL服务启动,简单来说,就是操作系统加载MySQL相关的文件,然后启动MySQL守护进程。这其中涉及到配置
