この記事は、Python に関する関連知識を提供します。Python は 3.7 で contextvars というモジュールを導入しました。名前から、コンテキスト変数を参照していることが簡単にわかります。以下にその方法を詳しく説明します。 contextvars を使用してコンテキスト変数を管理します。お役に立てば幸いです。
[関連する推奨事項: Python3 ビデオ チュートリアル ]
Python は 3.7 でモジュール contextvars を導入しました。その名前は簡単です。それがコンテキスト変数 (Context Variables) を参照していることを確認するには、contextvars を導入する前に、まずコンテキスト (Context) が何であるかを理解する必要があります。
コンテキストは、関連情報を含むオブジェクトです。例: 「たとえば、13 話のアニメでは、8 話目に直接クリックすると、ヒロインがヒーローの前で泣いているのが表示されます。」あなたは前のエピソードの内容を見ておらず、関連する文脈情報が欠けているため、なぜこの時点でヒロインが泣いているのか分からないと思います。
つまり、コンテキストは魔法のものではなく、その機能は特定の情報を運ぶことです。
fastapi と sanic を例として、リクエストが受信されたときにそれらがどのように解析するかを確認します。
# 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)テストリクエストを送信して、結果が正しいかどうかを確認します。
リクエストがすべて成功し、fastapi と sanic のリクエスト関数とビュー関数が結合されていることがわかります。つまり、リクエストが来ると、それは Request オブジェクトにカプセル化されてからビュー関数に渡されます。
しかし、これは flask には当てはまらないので、flask がリクエスト パラメーターを受け取る方法を見てみましょう。
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)フラスコの場合、インポート リクエストを介していることがわかります。必要ない場合は、インポートする必要はありません。もちろん、ここではどちらの方法が優れているかを比較していません。主にトピックを紹介するためです。今日。 。まず、flask の場合、別のビュー関数を定義した場合、同じようにリクエストパラメータが取得されるのですが、そこで問題が発生し、異なるビュー関数が内部で同じリクエストを使用した場合、競合が発生しないでしょうか?
flask を使用した経験に基づくと、答えは明らかにノーであり、その理由は ThreadLocal です。
ThreadLocal は、名前から判断すると、間違いなくスレッドに関連していると結論付けることができます。そうです、これは特にローカル変数を作成するために使用され、作成されたローカル変数はスレッドにバインドされます。
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
"""各スレッドには独自の一意の ID があるため、2 つのスレッドが互いに影響を与えていないことがわかります。値をバインドすると、現在のスレッドにバインドされ、取得も取得されます。現在のスレッドからのものです。 ThreadLocal を辞書として考えることができます:
{
"one": {"value": "ONE"},
"two": {"value": "TWO"}
}より正確には、キーはスレッドの ID である必要があります。直感的に理解するために、代わりにスレッドの名前を使用しますが、要するに、取得するときに、 、スレッドにバインドされたキーのみが取得され、スレッド上の変数の値が取得されます。
Flask もこのように設計されていますが、threading.local を直接使用するのではなく、Local クラスを実装します。スレッドのサポートに加えて、グリーンレット コルーチンもサポートします。では、どのように実装されているのでしょうか? ?まず、flask 内には「リクエスト コンテキスト」と「アプリケーション コンテキスト」があり、これらはスタック (2 つの異なるスタック) を通じて維持されることがわかります。
# 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"))
各リクエストは現在のコンテキストにバインドされ、リクエストの完了後に破棄されます。このプロセスはフレームワークによって完了するため、開発者はリクエストを直接使用するだけで済みます。したがって、リクエスト プロセスの具体的な詳細はソース コードで確認できます。ここでは、変数の設定と取得の鍵となる、前述の Local クラスである werkzeug.local.Local という 1 つのオブジェクトに焦点を当てます。ソース コードの一部を直接見てください:
# 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)したがって、flask の内部ロジックは実際には非常に単純であり、スレッド間の分離は ThreadLocal によって実現されていることがわかります。各リクエストは独自のコンテキストにバインドされ、値を取得するときに、関連情報を保存するために使用されるため、値はそれぞれのコンテキストからも取得されます (重要なことに、分離も実現します)。
これに応じて、この時点でコンテキストは理解できましたが、ここで問題が発生します。threading.local であれ、flask 自体によって実装された Local であれ、それらはすべてスレッド用です。 async def で定義されたコルーチンを使用する場合はどうすればよいですか?各コルーチンのコンテキスト分離を実現するにはどうすればよいでしょうか?それで、最後に私たちの主人公である contextvars が紹介されます。
このモジュールは、コルーチン内のローカル コンテキストの状態を管理、設定、およびアクセスするために使用できる一連のインターフェイスを提供します。
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 には、値を取得および設定するための 2 つのメソッド (get および set) が用意されています。効果は ThreadingLocal に似ていることがわかり、データはコルーチン間で分離され、相互の影響を受けません。
但我们再仔细观察一下，我们是在 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：
如果 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.set 的时候，其实会返回一个 Token 对象：
import contextvars
c = contextvars.ContextVar("context_var")
token = c.set("val")
print(token)
"""
<Token var=<ContextVar name='context_var' 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()) # val3Token 对象还有一个 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 对象和设置的值之间的映射，但是我们不会直接通过 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视频教程 】
以上がPython が contextvars を使用してコンテキスト変数を管理する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
