Comment Python utilise les variables de contexte pour gérer les variables de contexte

Cet article vous apporte des connaissances pertinentes sur Python. Python a introduit un module dans la version 3.7 : contextvars Il est facile de voir à partir du nom qu'il fait référence à des variables de contexte. Parlons-en en détail ci-dessous. contextvars pour gérer les variables de contexte. J'espère que cela sera utile à tout le monde.

[Recommandation associée : Tutoriel vidéo Python3 ]

Python a introduit un module en 3.7 : contextvars Il est facile de voir d'après le nom qu'il fait référence à des variables de contexte (Context Variables), donc dans l'introduction Avant. contextvars nous devons comprendre ce qu'est le contexte.

Context est un objet qui contient des informations pertinentes. Par exemple : "Par exemple, dans un anime de 13 épisodes, vous cliquez directement sur le huitième épisode et voyez l'héroïne pleurer devant le héros." Je crois que vous ne savez pas pourquoi l'héroïne pleure à ce moment-là, car vous n'avez pas regardé le contenu des épisodes précédents et il vous manque des informations contextuelles pertinentes.

Le contexte n'est donc pas une chose magique, sa fonction est de véhiculer certaines informations spécifiées.

Requête dans le framework Web

Prenons fastapi et sanic comme exemples pour voir comment ils analysent une demande lorsqu'elle arrive.

# fastapi
from fastapi import FastAPI, Request
import uvicorn

app = FastAPI()


@app.get("/index")
async def index(request: Request):
    name = request.query_params.get("name")
    return {"name": name}


uvicorn.run("__main__:app", host="127.0.0.1", port=5555)

# -------------------------------------------------------

# sanic
from sanic import Sanic
from sanic.request import Request
from sanic import response

app = Sanic("sanic")


@app.get("/index")
async def index(request: Request):
    name = request.args.get("name")
    return response.json({"name": name})


app.run(host="127.0.0.1", port=6666)

Envoyez une demande pour tester et voir si le résultat est correct.

Vous pouvez voir que les requêtes réussissent toutes, et pour fastapi et sanic, leurs fonctions de requête et d'affichage sont liées entre elles. Autrement dit, lorsque la requête arrive, elle sera encapsulée dans un objet Request puis transmise à la fonction d'affichage.

Mais ce n'est pas le cas pour flask. Voyons comment flask reçoit les paramètres de requête.

from flask import Flask, request

app = Flask("flask")


@app.route("/index")
def index():
    name = request.args.get("name")
    return {"name": name}


app.run(host="127.0.0.1", port=7777)

Nous voyons que pour flask, c'est via une demande d'importation. Si ce n'est pas nécessaire, il n'est pas nécessaire d'importer. Bien sûr, je ne compare pas quelle méthode est la meilleure ici, principalement pour présenter notre sujet d'aujourd'hui. Tout d'abord, pour flask, si je définis une autre fonction de vue, alors les paramètres de la requête sont toujours obtenus de la même manière, mais alors le problème se pose si différentes fonctions de vue utilisent la même requête en interne, n'y aura-t-il pas un conflit ?

Évidemment, sur la base de notre expérience dans l'utilisation de flask, la réponse est non, et la raison est ThreadLocal.

ThreadLocal

ThreadLocal, d'après son nom, vous pouvez dire qu'il est définitivement lié aux fils de discussion. C'est vrai, il est spécifiquement utilisé pour créer des variables locales, et les variables locales créées sont liées aux threads.

import threading

# 创建一个 local 对象
local = threading.local()

def get():
    name = threading.current_thread().name
    # 获取绑定在 local 上的 value
    value = local.value
    print(f"线程: {name}, value: {value}")

def set_():
    name = threading.current_thread().name
    # 为不同的线程设置不同的值
    if name == "one":
        local.value = "ONE"
    elif name == "two":
        local.value = "TWO"
    # 执行 get 函数
    get()

t1 = threading.Thread(target=set_, name="one")
t2 = threading.Thread(target=set_, name="two")
t1.start()
t2.start()
"""
线程 one, value: ONE
线程 two, value: TWO
"""

Vous pouvez voir que les deux threads n'ont aucune influence l'un sur l'autre, car chaque thread a son propre identifiant unique. Lors de la liaison de la valeur, elle sera liée au thread actuel et l'acquisition se fera également à partir du thread actuel. . obtenu en. Vous pouvez considérer ThreadLocal comme un dictionnaire :

{
    "one": {"value": "ONE"},
    "two": {"value": "TWO"}
}

Plus précisément, la clé doit être l'identifiant du thread. Par souci d'intuition, nous utilisons plutôt le nom du thread, mais en bref, uniquement les variables liées au thread. le fil sera obtenu lors de l’obtention de la valeur.

Flask est également conçu de cette manière en interne, mais il n'utilise pas directement threading.local, mais implémente une classe Local en plus de prendre en charge les threads, il prend également en charge les coroutines greenlet. Tout d'abord, nous savons qu'il existe un « contexte de demande » et un « contexte d'application » à l'intérieur de flask, qui sont maintenus via des piles (deux piles différentes).

# flask/globals.py
_request_ctx_stack = LocalStack()
_app_ctx_stack = LocalStack()
current_app = LocalProxy(_find_app)
request = LocalProxy(partial(_lookup_req_object, "request"))
session = LocalProxy(partial(_lookup_req_object, "session"))

Chaque requête sera liée au contexte actuel et sera détruite une fois la requête terminée. Ce processus est terminé par le framework, et les développeurs n'ont qu'à utiliser la requête directement. Par conséquent, les détails spécifiques du processus de requête peuvent être visualisés dans le code source. Ici, nous nous concentrons sur un objet : werkzeug.local.Local, qui est la classe Local mentionnée ci-dessus. C'est la clé pour définir et obtenir des variables. Jetez un œil directement à une partie du code source :

# werkzeug/local.py

class Local(object):
    __slots__ = ("__storage__", "__ident_func__")

    def __init__(self):
        # 内部有两个成员：__storage__ 是一个字典，值就存在这里面
        # __ident_func__ 只需要知道它是用来获取线程 id 的即可
        object.__setattr__(self, "__storage__", {})
        object.__setattr__(self, "__ident_func__", get_ident)

    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:
            # 根据线程 id 得到 value（一个字典）
            # 然后再根据 name 获取对应的值
            # 所以只会获取绑定在当前线程上的值
            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:
            # 将线程 id 作为 key，然后将值设置在对应的字典中
            # 所以只会将值设置在当前的线程中
            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)

Nous voyons donc que la logique interne de flask est en fait très simple et que l'isolation entre les threads est réalisée via ThreadLocal. Chaque requête sera liée à son propre contexte, et lors de l'obtention de la valeur, elle sera également obtenue à partir du contexte respectif, car elle est utilisée pour sauvegarder les informations pertinentes (surtout, elle réalise également l'isolement).

En conséquence, vous avez compris le contexte à ce stade, mais voici le problème. Qu'il s'agisse de threading.local ou de Local implémenté par flask lui-même, ils sont tous destinés aux threads. Que dois-je faire si j'utilise une coroutine définie par async def ? Comment réaliser l'isolation du contexte de chaque coroutine ? Enfin, notre protagoniste est présenté : les contextvars.

contextvars

Ce module fournit un ensemble d'interfaces qui peuvent être utilisées pour gérer, définir et accéder à l'état du contexte local dans les coroutines.

import asyncio
import contextvars

c = contextvars.ContextVar("只是一个标识, 用于调试")

async def get():
    # 获取值
    return c.get() + "~~~"

async def set_(val):
    # 设置值
    c.set(val)
    print(await get())

async def main():
    coro1 = set_("协程1")
    coro2 = set_("协程2")
    await asyncio.gather(coro1, coro2)


asyncio.run(main())
"""
协程1~~~
协程2~~~
"""

ContextVar fournit deux méthodes, get et set, pour obtenir et définir des valeurs. Nous voyons que l'effet est similaire à ThreadingLocal. Les données sont isolées entre les coroutines et ne seront pas affectées les unes par les autres.

但我们再仔细观察一下，我们是在 set_ 函数中设置的值，然后在 get 函数中获取值。可 await get() 相当于是开启了一个新的协程，那么意味着设置值和获取值不是在同一个协程当中。但即便如此，我们依旧可以获取到希望的结果。因为 Python 的协程是无栈协程，通过 await 可以实现级联调用。

我们不妨再套一层：

import asyncio
import contextvars

c = contextvars.ContextVar("只是一个标识, 用于调试")

async def get1():
    return await get2()

async def get2():
    return c.get() + "~~~"

async def set_(val):
    # 设置值
    c.set(val)
    print(await get1())
    print(await get2())

async def main():
    coro1 = set_("协程1")
    coro2 = set_("协程2")
    await asyncio.gather(coro1, coro2)


asyncio.run(main())
"""
协程1~~~
协程1~~~
协程2~~~
协程2~~~
"""

我们看到不管是 await get1() 还是 await get2()，得到的都是 set_ 中设置的结果，说明它是可以嵌套的。

并且在这个过程当中，可以重新设置值。

import asyncio
import contextvars

c = contextvars.ContextVar("只是一个标识, 用于调试")

async def get1():
    c.set("重新设置")
    return await get2()

async def get2():
    return c.get() + "~~~"

async def set_(val):
    # 设置值
    c.set(val)
    print("------------")
    print(await get2())
    print(await get1())
    print(await get2())
    print("------------")

async def main():
    coro1 = set_("协程1")
    coro2 = set_("协程2")
    await asyncio.gather(coro1, coro2)


asyncio.run(main())
"""
------------
协程1~~~
重新设置~~~
重新设置~~~
------------
------------
协程2~~~
重新设置~~~
重新设置~~~
------------
"""

先 await get2() 得到的就是 set_ 函数中设置的值，这是符合预期的。但是我们在 get1 中将值重新设置了，那么之后不管是 await get1() 还是直接 await get2()，得到的都是新设置的值。

这也说明了，一个协程内部 await 另一个协程，另一个协程内部 await 另另一个协程，不管套娃（await）多少次，它们获取的值都是一样的。并且在任意一个协程内部都可以重新设置值，然后获取会得到最后一次设置的值。再举个栗子：

import asyncio
import contextvars

c = contextvars.ContextVar("只是一个标识, 用于调试")

async def get1():
    return await get2()

async def get2():
    val = c.get() + "~~~"
    c.set("重新设置啦")
    return val

async def set_(val):
    # 设置值
    c.set(val)
    print(await get1())
    print(c.get())

async def main():
    coro = set_("古明地觉")
    await coro

asyncio.run(main())
"""
古明地觉~~~
重新设置啦
"""

await get1() 的时候会执行 await get2()，然后在里面拿到 c.set 设置的值，打印 "古明地觉~~~"。但是在 get2 里面，又将值重新设置了，所以第二个 print 打印的就是新设置的值。\

如果在 get 之前没有先 set，那么会抛出一个 LookupError，所以 ContextVar 支持默认值：

import asyncio
import contextvars

c = contextvars.ContextVar("只是一个标识, 用于调试",
                           default="哼哼")

async def set_(val):
    print(c.get())
    c.set(val)
    print(c.get())

async def main():
    coro = set_("古明地觉")
    await coro

asyncio.run(main())
"""
哼哼
古明地觉
"""

除了在 ContextVar 中指定默认值之外，也可以在 get 中指定：

import asyncio
import contextvars

c = contextvars.ContextVar("只是一个标识, 用于调试",
                           default="哼哼")

async def set_(val):
    print(c.get("古明地恋"))
    c.set(val)
    print(c.get())

async def main():
    coro = set_("古明地觉")
    await coro

asyncio.run(main())
"""
古明地恋
古明地觉
"""

所以结论如下，如果在 c.set 之前使用 c.get：

• 当 ContextVar 和 get 中都没有指定默认值，会抛出 LookupError；
• 只要有一方设置了，那么会得到默认值；
• 如果都设置了，那么以 get 为准；

如果 c.get 之前执行了 c.set，那么无论 ContextVar 和 get 有没有指定默认值，获取到的都是 c.set 设置的值。

所以总的来说还是比较好理解的，并且 ContextVar 除了可以作用在协程上面，它也可以用在线程上面。没错，它可以替代 threading.local，我们来试一下：

import threading
import contextvars

c = contextvars.ContextVar("context_var")

def get():
    name = threading.current_thread().name
    value = c.get()
    print(f"线程 {name}, value: {value}")

def set_():
    name = threading.current_thread().name
    if name == "one":
        c.set("ONE")
    elif name == "two":
        c.set("TWO")
    get()

t1 = threading.Thread(target=set_, name="one")
t2 = threading.Thread(target=set_, name="two")
t1.start()
t2.start()
"""
线程 one, value: ONE
线程 two, value: TWO
"""

和 threading.local 的表现是一样的，但是更建议使用 ContextVars。不过前者可以绑定任意多个值，而后者只能绑定一个值（可以通过传递字典的方式解决这一点）。

c.Token

当我们调用 c.set 的时候，其实会返回一个 Token 对象：

import contextvars

c = contextvars.ContextVar("context_var")
token = c.set("val")
print(token)
"""
<Token var=<ContextVar name=&#39;context_var&#39; at 0x00..> at 0x00...>
"""

Token 对象有一个 var 属性，它是只读的，会返回指向此 token 的 ContextVar 对象。

import contextvars

c = contextvars.ContextVar("context_var")
token = c.set("val")

print(token.var is c)  # True
print(token.var.get())  # val

print(
    token.var.set("val2").var.set("val3").var is c
)  # True
print(c.get())  # val3

Token 对象还有一个 old_value 属性，它会返回上一次 set 设置的值，如果是第一次 set，那么会返回一个 。

import contextvars

c = contextvars.ContextVar("context_var")
token = c.set("val")

# 该 token 是第一次 c.set 所返回的
# 在此之前没有 set，所以 old_value 是 <Token.MISSING>
print(token.old_value)  # <Token.MISSING>

token = c.set("val2")
print(c.get())  # val2
# 返回上一次 set 的值
print(token.old_value)  # val

那么这个 Token 对象有什么作用呢？从目前来看貌似没太大用处啊，其实它最大的用处就是和 reset 搭配使用，可以对状态进行重置。

import contextvars
#### 
c = contextvars.ContextVar("context_var")
token = c.set("val")
# 显然是可以获取的
print(c.get())  # val

# 将其重置为 token 之前的状态
# 但这个 token 是第一次 set 返回的
# 那么之前就相当于没有 set 了
c.reset(token)
try:
    c.get()  # 此时就会报错
except LookupError:
    print("报错啦")  # 报错啦

# 但是我们可以指定默认值
print(c.get("默认值"))  # 默认值

contextvars.Context

它负责保存 ContextVars 对象和设置的值之间的映射，但是我们不会直接通过 contextvars.Context 来创建，而是通过 contentvars.copy_context 函数来创建。

import contextvars

c1 = contextvars.ContextVar("context_var1")
c1.set("val1")
c2 = contextvars.ContextVar("context_var2")
c2.set("val2")

# 此时得到的是所有 ContextVar 对象和设置的值之间的映射
# 它实现了 collections.abc.Mapping 接口
# 因此我们可以像操作字典一样操作它
context = contextvars.copy_context()
# key 就是对应的 ContextVar 对象，value 就是设置的值
print(context[c1])  # val1
print(context[c2])  # val2
for ctx, value in context.items():
    print(ctx.get(), ctx.name, value)
    """
    val1 context_var1 val1
    val2 context_var2 val2
    """

print(len(context))  # 2

除此之外，context 还有一个 run 方法：

import contextvars

c1 = contextvars.ContextVar("context_var1")
c1.set("val1")
c2 = contextvars.ContextVar("context_var2")
c2.set("val2")

context = contextvars.copy_context()

def change(val1, val2):
    c1.set(val1)
    c2.set(val2)
    print(c1.get(), context[c1])
    print(c2.get(), context[c2])

# 在 change 函数内部，重新设置值
# 然后里面打印的也是新设置的值
context.run(change, "VAL1", "VAL2")
"""
VAL1 VAL1
VAL2 VAL2
"""

print(c1.get(), context[c1])
print(c2.get(), context[c2])
"""
val1 VAL1
val2 VAL2
"""

我们看到 run 方法接收一个 callable，如果在里面修改了 ContextVar 实例设置的值，那么对于 ContextVar 而言只会在函数内部生效，一旦出了函数，那么还是原来的值。但是对于 Context 而言，它是会受到影响的，即便出了函数，也是新设置的值，因为它直接把内部的字典给修改了。

小结

以上就是 contextvars 模块的用法，在多个协程之间传递数据是非常方便的，并且也是并发安全的。如果你用过 Go 的话，你应该会发现和 Go 在 1.7 版本引入的 context 模块比较相似，当然 Go 的 context 模块功能要更强大一些，除了可以传递数据之外，对多个 goroutine 的级联管理也提供了非常清蒸的解决方案。

总之对于 contextvars 而言，它传递的数据应该是多个协程之间需要共享的数据，像 cookie, session, token 之类的，比如上游接收了一个 token，然后不断地向下透传。但是不要把本应该作为函数参数的数据，也通过 contextvars 来传递，这样就有点本末倒置了。

【相关推荐：Python3视频教程 】

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!