Is this Python running with the GIL?
The browser runs the standard 3.13 build, so the GIL is on. On a free-threaded build the second and third lines would differ.
The Global Interpreter Lock (GIL) lets only one thread run Python bytecode at a time in the standard CPython build, so threads do not speed up pure-Python calculation but still help with waiting. A free-threaded build without the GIL exists (experimental in 3.13, officially supported in 3.14).
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 6 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Print whether your interpreter runs with the GIL, in the form GIL: True, using a safe fallback for versions older than 3.13.
Use dis to show the bytecode of a function bump(d, k) that does d[k] += 1. Which instructions read, add and store?
Explain in one sentence each why list.append from many threads does not corrupt the list, while counter += 1 can lose updates.
Explain it without notes
What is the GIL, and what does it protect?
Why do threads speed up an I/O-bound program but not a CPU-bound pure-Python one?
If the GIL exists, why do you still need locks in threaded Python code?
What are the free-threaded build and sub-interpreters, and what is their status?
Your threaded counter test passes on your machine, even with 4 threads and a million increments each and no lock. Is the code safe? What would you do?
Expected output
Python: 3 13
GIL enabled right now: True
Free-threaded build: False
Thread switch interval (seconds): 0.005