Body

Fixes the 3.15 regression where subprocess.Popen.wait(timeout=...) (and
subprocess.run(..., timeout=...)) fails for very large timeout values such
as float("inf"), sys.maxsize or 1e10 — all accepted on 3.14 and
earlier. The event-driven wait introduced by gh-83069 (#144047) passes the
caller's timeout unclamped to poll() / kqueue.control(); values that do
not fit the C timestamp conversion raise OverflowError on Linux and, on
macOS/BSD, a misleading TypeError: timeout must be a real number or None, not float.

Changes

• Lib/subprocess.py — both _wait_pidfd() and _wait_kqueue() now
  clamp each OS-level wait to a new module constant
  _MAXIMUM_WAIT_TIMEOUT = 24 * 3600 (following asyncio's
  MAXIMUM_SELECT_TIMEOUT precedent, Lib/asyncio/base_events.py) and loop
  until the caller's real deadline, so TimeoutExpired is still raised at
  the right time and huge-but-legal timeouts never reach the C conversion.
  In _wait_kqueue() the kevent changelist is only submitted on the first
  control() call (the KQ_EV_ADD | KQ_EV_ONESHOT registration persists
  across timed-out waits).
• Modules/selectmodule.c — the kqueue control() timeout-conversion
  failure is now only rewritten into the "timeout must be a real number or
  None" TypeError when the original exception is a TypeError, guarded
  by PyErr_ExceptionMatches(PyExc_TypeError) exactly like the sibling
  select(), poll(), devpoll() and epoll() sites already do. Huge
  timeouts now surface the true OverflowError instead of a false claim
  that a float is not a real number.

Tests

• Lib/test/test_subprocess.py (FastWaitTestCase):
  test_wait_huge_timeout (10**10, sys.maxsize, float('inf')),
  test_run_huge_timeout (the run()/communicate() path), and
  test_wait_slices_do_not_expire_early (with the slice limit patched down
  to 10 ms, a process outliving many slices is still waited for — guards
  against a clamp that fires TimeoutExpired at the slice boundary). All
  POSIX-gated: the Windows _wait has a separate, pre-existing
  int(timeout * 1000) overflow for float("inf") that predates 3.15 and
  is deliberately out of scope here.
• Lib/test/test_kqueue.py: test_control_overflowing_timeout — an
  out-of-range timeout raises OverflowError, not TypeError; non-numbers
  still raise TypeError.

How tested

On macOS (arm64), against a 3.15.0b4 build with the patched
subprocess.py overlaid: the three new test_subprocess tests pass, the
entire pre-existing FastWaitTestCase and the POSIX wait-related suite
stay green, and wait(timeout=float("inf")) / run(..., timeout=1e10)
succeed. The Python-level clamp alone already fixes the user-visible
wait()/run() breakage (the overflowing value never reaches
kq.control()). The test_kqueue addition and the OverflowError
surfacing require the rebuilt select module (verified expected-fail
against the unpatched 3.15.0b4 C module); the Linux _wait_pidfd loop is
exercised by the new tests on Linux CI.

• Issue: 3.15 regression: Popen.wait(timeout=float("inf")) raises TypeError: timeout must be a real number or None on macOS/BSD (new kqueue wait path) #154836

NEWS entry (already in the commit, blurb format)

Misc/NEWS.d/next/Library/2026-07-19-20-00-00.gh-issue-154836.kqWait.rst:

Fix :meth:subprocess.Popen.wait raising :exc:TypeError (macOS and other
BSDs) or :exc:OverflowError (Linux) for very large timeout values such
as float('inf'), a 3.15 regression in the new event-driven wait. Also
fix :meth:select.kqueue.control masking :exc:OverflowError for
out-of-range timeouts as :exc:TypeError.