[pre-commit.ci] pre-commit autoupdate

.pre-commit-config.yaml

@@ -22,14 +22,14 @@ repos:
       - id: black
 
   - repo: https://github.com/rbubley/mirrors-prettier
-    rev: 787fb9f542b140ba0b2aced38e6a3e68021647a3 # frozen: v3.5.3
+    rev: 5ba47274f9b181bce26a5150a725577f3c336011 # frozen: v3.6.2
     hooks:
       - id: prettier
         files: \.(md|yml|yaml)
         args: [--prose-wrap=preserve]
 
   - repo: https://github.com/asottile/pyupgrade
-    rev: ce40a160603ab0e7d9c627ae33d7ef3906e2d2b2 # frozen: v3.19.1
+    rev: 37bfa06d791fd38fb4e54910b36a2ff57641b074 # frozen: v3.20.0
     hooks:
       - id: pyupgrade
         args: [--py38-plus]

spec-0002/index.md

@@ -58,7 +58,6 @@ A successful prototype implementation of this SPEC is already integrated into [N
 
 2.  Backend Requirements
     To ensure that a backend is compatible with NetworkX, it must adhere to specific structural requirements:
-
     1. The backend must implement a class that behaves like the `nx.Graph` object, including an attribute `__networkx_backend__` that identifies the backend.
 
     2. The backend should provide `convert_from_nx` and `convert_to_nx` methods to facilitate the conversion between NetworkX graphs and the backend's graph representation.
@@ -70,7 +69,6 @@ A successful prototype implementation of this SPEC is already integrated into [N
         pytest --pyargs networkx
 
 4.  Currently, the following ways exist in NetworkX to dispatch a function call to a backend:
-
     1. Type-based dispatching
        ```py
        H = nx_parallel.ParallelGraph(G)

spec-0005/index.md

@@ -85,7 +85,6 @@ and other ancillary information as needed.
 - Recommend that CI running against PRs be expected to pass--if it fails, it should be important
 
 - Schedule regular runs of CI against nightlies/pre-releases
-
   - Good for other checks that don't need to run on every PR
   - Could use for pins
   - Can use labels to trigger additional runs of "exotic" jobs

spec-0006/index.md

@@ -59,7 +59,6 @@ This document deals with the situation in which that is not possible, and secret
    This ensures access to assets, even when a key team member leaves the project or becomes indisposed.
 
 4. A system for distributing project secrets must have the following properties:
-
    - Secrets are stored encrypted in a central (remote) location.
    - It must be possible to grant access to the secrets to a select group of team members.
    - It must be possible to revoke future access to the secrets.[^future-access]

spec-0007/index.md

@@ -99,7 +99,6 @@ The [deprecation strategy](https://github.com/scientific-python/specs/pull/180#i
 
 - If neither `rng` nor `random_state`/`seed`/`...` is specified and `np.random.seed` has been used to set the seed, emit a `FutureWarning` about the upcoming change in behavior.
 - If `random_state`/`seed`/`...` is passed by keyword or by position, treat it as before, but:
-
   - Emit a `DeprecationWarning` if passed by keyword, warning about the deprecation of keyword `random_state` in favor of `rng`.
   - Emit a `FutureWarning` if passed by position, warning about the change in behavior of the positional argument.