python / python/cpython

Tracking issue for free-threading docs

オープン
#145,912 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

3.14 3.15 docs topic-free-threading
主要言語
Python
スター
77.2k
フォーク
35.9k
PR マージ指標
PR 指標を取得中

説明

Documentation

Summary

This is a tracking issue for the ongoing effort to improve thread safety documentation in CPython, covering both Python-level guarantees for built-in types and C API-level annotations for extension authors.

Completed work

Thread safety page and built-in type guarantees (gh-142518)
  • Define free-threading related terms in the glossary
  • gh-142519
  • gh-144184
  • gh-144716
  • gh-145224
C API thread safety annotations (gh-145254)
  • Define five annotation levels: incompatible, compatible, distinct, shared, atomic
  • gh-145255
  • Add thread safety levels reference section to threadsafety.rst
  • Open python-docs-theme PR for rendering support

In progress (at the time of writing)

  • gh-145225
  • gh-145226
  • gh-145911
  • gh-145875
  • gh-146109

Remaining work

stdlib type documentation

After built-in types, document thread-safety guarantees for stdlib types. Suggested priority:

  • collections.deque - widely used as a thread-safe queue substitute; people already assume it's safe; heavily used in asyncio internals
  • io types (BufferedReader, BufferedWriter, TextIOWrapper) - file I/O is inherently concurrent in real programs; existing thread-safety notes are scattered and incomplete
  • collections.defaultdict - the __missing__ call introduces non-obvious concurrency questions (factory call is not atomic with insertion)
  • collections.OrderedDict - has its own internal locking that differs from plain dict
  • collections.Counter - commonly used for aggregation across threads
  • array.array - mutable typed array, relevant for numeric/scientific code going parallel

Rationale: deque first because it's the most likely to be shared across threads today. io types next because concurrent file access is common and the current docs are inadequate. The collections types after that, ordered by usage frequency and concurrency risk. array.array last - niche usage, but mutable so still worth documenting.

Free-threading programming guide (new HOWTO)

A new Doc/howto/free-threading-guide.rst, alongside the existing two free-threading HOWTOs. The existing free-threading-python.rst stays focused on "what is free-threading / what changed." The new guide focuses on how to write correct concurrent code.

Topics to cover:

  • Single operations vs. compound operations - why "thread-safe" doesn't mean "atomic"
  • Common pitfalls: check-then-act, read-modify-write, iterating shared containers
  • When and how to use threading.Lock and other synchronization primitives
  • Practical patterns: queues, concurrent.futures, thread-local storage
  • How to migrate existing threaded code that relied on the GIL
  • Testing and debugging strategies (ThreadSanitizer, running under free-threaded builds)
  • Summary reference table of built-in type thread safety (quick lookup, links to detailed per-type docs)

Cross-reference from free-threading-python.rst and from the per-type thread safety page.

asyncio free-threaded guide
Other documentation gaps
  • Review and improve queue module docs w.r.t. free-threaded builds
  • Address gh-84992
  • Address gh-83556
C API annotations
  • Annotate PyObject_* APIs (creation, attribute access, comparison, etc.)
  • Annotate abstract layer APIs
    • PySequence_*
    • PyMapping_*
    • PyNumber_*
    • PyIter_*
  • Annotate reference counting APIs (Py_INCREF, Py_DECREF, Py_NewRef, etc.)
  • Annotate GIL/critical-section APIs
  • Annotate concrete type APIs
    • PyList_*
    • PyDict_*
    • PySet_*
    • PyTuple_*
    • PyUnicode_*
  • Annotate buffer protocol APIs (PyObject_GetBuffer, PyBuffer_Release, etc.)
  • Systematically work through remaining high-usage C API functions
Infrastructure improvements
  • Coordinate with gh-116738 (audit all built-in modules for thread safety) - ensure doc annotations stay in sync with implementation fixes
  • Add CI/linting to validate threadsafety.dat entries match actual function signatures
  • Consider generating per-module thread safety summary tables - especially in modules where it makes sense like collections

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

まず、残っている作業から、未チェックで自己完結した項目を1つ選びます。たとえば、stdlib の型を文書化する、または Doc/howto/free-threading-guide.rst を作成する、といった項目です。関連する既存のドキュメント(free-threading-python.rst と threadsafety.rst を含む)を読み、その後、選択したチェックリスト項目を完了し、要求された相互参照または注釈を追加します。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
python
領域
documentation
issue の種類
ドキュメント
難易度
5/5
見積もり時間
1週間以上
活発さ
静か
明瞭さ
説明が足りない
初心者へのやさしさ
25/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。