Add materials for What Is the Python Global Interpreter Lock (GIL)?

[realpython-bot]

New folder for a tutorial that never had one

This is a brand-new python-gil/ folder — the tutorial What Is the Python Global Interpreter Lock (GIL)? has never shipped companion code. That means this PR needs an editorial eye as well as a code review: someone should confirm the file names, the README framing, and the REPL-to-script conversions read the way the team wants them to before this is merged.

The code was taken from the updated draft, not the live article:

• Draft admin: https://realpython.com/pbjt/blog/post/2346/change/
• Live article (read-only reference, Post 122): https://realpython.com/python-gil/
• Maintenance card: https://trello.com/c/3VTsYPw1

What the folder contains, and how it maps to the article

File	Article section	Source in the article
reference_counting.py	What Problem Did the GIL Solve for Python?	pycon REPL block (sys.getrefcount())
single_threaded.py	The Impact on Multi-Threaded Python Programs	named script single_threaded.py
multi_threaded.py	The Impact on Multi-Threaded Python Programs	named script multi_threaded.py
switch_interval.py	Why Wasn't It Removed in Python 3?	pycon REPL block (sys.getswitchinterval())
multiprocess.py	How to Deal With Python's GIL	named script multiprocess.py
README.md	—	house form: title, tutorial link, script/section map, how-to-run

That is every code block in the article. Nothing was invented and no example was "improved" — the folder mirrors the tutorial.

REPL examples were turned into runnable scripts

The two pycon blocks became plain .py files that print() the value the prose is talking about, which is the convention in siblings like python-set/ and python-list/. Article order and variable names are preserved (a, b in reference_counting.py; the switch-interval comment is carried over verbatim). Each section's REPL sequence is one coherent script rather than one file per snippet — here each section only had a single short block, so that's one file each.

Two deliberate deviations from the article text, both to pass the repo's gates

1. single_threaded.py drops from threading import Thread. The article's listing imports Thread but never uses it in the single-threaded version. The repo's ruff config (select = ["E", "F", "RUF100"]) flags that as F401 and ruff check fails. The import is removed here. This is arguably a bug in the article too — worth fixing in draft 2346 so the two stay in sync.
2. House formatting applied. The article uses single quotes and while n>0:; ruff format normalizes these to double quotes and while n > 0:. Logic, values, and structure are untouched.

No requirements.txt

The draft's dependencies field is python==3.14 — no third-party packages. Per the repo convention for stdlib-only tutorials (python-deque/, python-repl/, python-set/, python-list/ all do this), the folder ships no requirements.txt.

How this was verified

Everything was actually executed — nothing was skipped, and nothing in this folder needs a server, a GUI, or a paid API key.

1. Ran every file in a fresh venv on the article's pin (CPython 3.14.6), with MPLBACKEND=Agg exported:

$ python reference_counting.py
3
$ python switch_interval.py
0.005
$ python single_threaded.py
Time taken in seconds - 1.9375929832458496
$ python multi_threaded.py
Time taken in seconds - 2.0882744789123535
$ python multiprocess.py
Time taken in seconds - 1.1493613719940186

Checked against the article:

• reference_counting.py prints 3, exactly the value the article shows.
• switch_interval.py prints 0.005, exactly the value the article shows.
• The three timings reproduce the article's argument, though not its absolute numbers — the article's author was on 4 cores and this ran on 2. Threaded is slightly slower than single-threaded (2.09s vs 1.94s), which is the article's point that the GIL stops CPU-bound threads running in parallel and adds acquire/release overhead. multiprocess.py is the fastest (1.15s) but well short of halving the time, which is the article's point about process-management overhead. The README warns readers that these numbers are machine-dependent.

2. The repo's own gates, at the version the root requirements.txt pins (ruff==0.14.1):

$ uvx ruff@0.14.1 format --check python-gil
5 files already formatted
$ uvx ruff@0.14.1 check python-gil
All checks passed!

The folder name and its README.md also satisfy .github/workflows/dircheck.py.

Only python-gil/ is touched by this PR. git status --porcelain and git clean -nd are both empty — no venvs, caches, or generated output.