Context variables and thread-local data

Practice that adapts to you

Practise this lesson

10 questions about 11 ideas of this lesson. Each answer is explained at once, and what you get right is kept in this browser.

1. Question 1 of 10 What does shared_global.py print?

   What does this program print? Choose one answer.

   import asyncio
   from contextvars import ContextVar
   
   current_request = "-"                                   # one global for the whole program
   request_id = ContextVar("request_id", default="-")      # one value per context
   
   
   def log_global(message):
       print(f"[{current_request}] {message}")
   
   
   def log_context(message):
       print(f"[{request_id.get()}] {message}")
   
   
   async def handle_with_global(rid, item):
       global current_request
       current_request = rid
       await asyncio.sleep(0)              # a database call: other tasks run meanwhile
       log_global(f"loaded {item}")
   
   
   async def handle_with_contextvar(rid, item):
       request_id.set(rid)
       await asyncio.sleep(0)
       log_context(f"loaded {item}")
   
   
   async def main():
       print("with a global:")
       async with asyncio.TaskGroup() as tg:
           tg.create_task(handle_with_global("r-17", "cart"))
           tg.create_task(handle_with_global("r-42", "invoice"))
       print("with a ContextVar:")
       async with asyncio.TaskGroup() as tg:
           tg.create_task(handle_with_contextvar("r-17", "cart"))
           tg.create_task(handle_with_contextvar("r-42", "invoice"))
       print("main still sees:", repr(request_id.get()))
   
   
   asyncio.run(main())

   with a global: [r-17] loaded cart [r-42] loaded invoice with a ContextVar: [r-17] loaded cart [r-42] loaded invoice main still sees: '-' with a global: [r-42] loaded cart [r-42] loaded invoice with a ContextVar: [r-17] loaded cart [r-42] loaded invoice main still sees: 'r-42' with a global: [r-42] loaded cart [r-42] loaded invoice with a ContextVar: [r-17] loaded cart [r-42] loaded invoice main still sees: '-'

   Show the answer: Question 1 of 10

   Answer: it prints

   with a global:
   [r-42] loaded cart
   [r-42] loaded invoice
   with a ContextVar:
   [r-17] loaded cart
   [r-42] loaded invoice
   main still sees: '-'

   Task A stores r-17 in the global and pauses at its await; task B stores r-42 before A logs, so both lines say r-42. With the ContextVar, each set() changes only the copy of the context that its own task runs in, so each task logs its own id and main() still reads the default.

2. Question 2 of 10 A handler runs current_request = rid, logs a line at once, and only then awaits the database. Which of its log lines are safe?

   Choose one answer.

   The line before the first await; any line after an await can carry another request's id None of them, because a global can never be read safely All of them, because the handler set the global itself All of them, as long as the event loop runs one task at a time

   Show the answer: Question 2 of 10

   Answer: The line before the first await; any line after an await can carry another request's id

   Tasks switch only at await points. Until this handler's first await, nobody else can write the global; after it, any line may read the id of whichever request wrote last.

3. Question 3 of 10 When does a new asyncio task get its copy of the context?

   Choose one answer.

   When asyncio.create_task() creates it Each time it resumes after an await When it finishes, to hand its values back Only when it calls ContextVar.set()

   Show the answer: Question 3 of 10

   Answer: When asyncio.create_task() creates it

   asyncio.create_task() copies the current context when it creates the task. From then on the task reads and writes only that copy.

4. Question 4 of 10 A handler sets request_id, starts a background task that sends an email, and returns at once. The email task logs a second later, after the handler's own task has finished. Which id does its line carry?

   Choose one answer.

   The default, because the handler's task has finished Whichever request the loop served last It raises LookupError, because its creator is gone The handler's request id, held in the task's own copy

   Show the answer: Question 4 of 10

   Answer: The handler's request id, held in the task's own copy

   A task sees the values its creator had set before creating it and keeps its copy for its whole life, so the email task logs the right id even after the handler has returned.

5. Question 5 of 10 What does a threading.local() object keep apart?

   Choose one answer.

   A copy of the program's globals for each thread Its attributes, one set per thread Its attributes, one set per asyncio task Nothing, because it is a lock that lets one thread in at a time

   Show the answer: Question 5 of 10

   Answer: Its attributes, one set per thread

   threading.local() gives every thread its own attributes on the same object. It separates threads, not tasks.

6. Question 6 of 10 A program runs jobs on the eight threads of a ThreadPoolExecutor, and each thread needs its own database connection, opened once and reused for every job that thread runs. Where do you keep the connection?

   Choose one answer.

   In a ContextVar set once by the main thread before the pool starts In a list with one entry per job In an attribute of a threading.local() object In a module-level global

   Show the answer: Question 6 of 10

   Answer: In an attribute of a threading.local() object

   The connection belongs to the thread, which is exactly what thread-local data is for: each worker thread sees its own attribute, and a job finds the connection its thread opened earlier. A global would be shared by every thread, and a value the main thread puts in a ContextVar does not reach the worker threads, which start with an empty context in the default build.

7. Question 7 of 10 Two asyncio tasks run on the same event loop. Each stores the current user in state.user, where state = threading.local(), then awaits a database call and reads state.user again. What can go wrong?

   Choose one answer.

   Nothing: threading.local() gives every asyncio task its own attributes Reading state.user after an await raises RuntimeError Both tasks run in the same thread, so the second task's assignment can overwrite the first task's user Each await clears the attributes of a threading.local() object

   Show the answer: Question 7 of 10

   Answer: Both tasks run in the same thread, so the second task's assignment can overwrite the first task's user

   Thread-local data is kept per thread, and every task of one event loop runs in the loop's thread. While the first task waits, the second one can replace the shared attribute, so the first task reads the wrong user after its await. A ContextVar keeps a value per task instead.

8. Question 8 of 10 A context variable has never been set. What is token.old_value for the token its first set() returns?

   Choose one answer.

   The variable's default Token.MISSING None The new value

   Show the answer: Question 8 of 10

   Answer: Token.MISSING

   A token remembers the previous value, or the marker Token.MISSING when there was none, as the program printed: token.old_value is Token.MISSING: True.

9. Question 9 of 10 What does this print on Python 3.14?

   Read the code, then choose one answer.

   from contextvars import ContextVar
   
   user = ContextVar("user", default="guest")
   with user.set("asha"):
       with user.set("ravi"):
           pass
       print(user.get(), end=" ")
   print(user.get())

   ravi guest asha guest guest guest ravi asha

   Show the answer: Question 9 of 10

   Answer: asha guest

   Each with block resets the variable to the value it had before its own set(). The inner block ends first and puts back "asha"; the outer block then puts back the default, "guest".

10. Question 10 of 10 Library code must also run on Python 3.13. How does it set a request id for one block of work and restore the old value afterwards?

    Choose one answer.

    with request_id.set(rid): around the work request_id.set(rid) before the work and request_id.set("-") after it del request_id after the work token = request_id.set(rid), the work in a try block, and request_id.reset(token) in finally

    Show the answer: Question 10 of 10

    Answer: token = request_id.set(rid), the work in a try block, and request_id.reset(token) in finally

    On 3.13 and older a token is not a context manager, so the try and finally form restores the old value whether the work succeeds or raises.