Merge pull request #3193 from python-trio/pre-commit-ci-update-config

[pre-commit.ci] pre-commit autoupdate

Author: CoolCat467

.pre-commit-config.yaml

@@ -24,14 +24,14 @@ repos:
     hooks:
       - id: black
   - repo: https://github.com/astral-sh/ruff-pre-commit
-    rev: v0.9.2
+    rev: v0.9.3
     hooks:
       - id: ruff
         types: [file]
         types_or: [python, pyi, toml]
         args: ["--show-fixes"]
   - repo: https://github.com/codespell-project/codespell
-    rev: v2.3.0
+    rev: v2.4.0
     hooks:
       - id: codespell
   - repo: https://github.com/crate-ci/typos
@@ -56,7 +56,7 @@ repos:
         additional_dependencies: ["astor", "attrs", "black", "ruff"]
         files: ^src\/trio\/_core\/(_run|(_i(o_(common|epoll|kqueue|windows)|nstrumentation)))\.py$
   - repo: https://github.com/astral-sh/uv-pre-commit
-    rev: 0.5.21
+    rev: 0.5.24
     hooks:
       # Compile requirements
       - id: pip-compile

docs/source/reference-core.rst

@@ -1797,7 +1797,7 @@ If you've used other I/O frameworks, you may have encountered the
 concept of a "thread pool", which is most commonly implemented as a
 fixed size collection of threads that hang around waiting for jobs to
 be assigned to them. These solve two different problems: First,
-re-using the same threads over and over is more efficient than
+reusing the same threads over and over is more efficient than
 starting and stopping a new thread for every job you need done;
 basically, the pool acts as a kind of cache for idle threads. And
 second, having a fixed size avoids getting into a situation where
@@ -1848,7 +1848,7 @@ into two layers. The lower layer is responsible for taking blocking
 I/O jobs and arranging for them to run immediately on some worker
 thread. It takes care of solving the tricky concurrency problems
 involved in managing threads and is responsible for optimizations like
-re-using threads, but has no admission control policy: if you give it
+reusing threads, but has no admission control policy: if you give it
 100,000 jobs, it will spawn 100,000 threads. The upper layer is
 responsible for providing the policy to make sure that this doesn't
 happen – but since it *only* has to worry about policy, it can be much

test-requirements.txt

@@ -28,7 +28,7 @@ charset-normalizer==3.4.1
     # via requests
 click==8.1.8 ; implementation_name == 'cpython'
     # via black
-codespell==2.3.0
+codespell==2.4.0
     # via -r test-requirements.in
 colorama==0.4.6 ; sys_platform == 'win32'
     # via
@@ -128,7 +128,7 @@ pyyaml==6.0.2
     # via pre-commit
 requests==2.32.3
     # via sphinx
-ruff==0.9.2
+ruff==0.9.3
     # via -r test-requirements.in
 sniffio==1.3.1
     # via -r test-requirements.in
@@ -181,7 +181,7 @@ typing-extensions==4.12.2
     #   pyright
 urllib3==2.3.0
     # via requests
-uv==0.5.21
+uv==0.5.24
     # via -r test-requirements.in
 virtualenv==20.28.0
     # via pre-commit