maint: Add additional linter-related pre-commit hooks (#3337)

* Add additional pygrep pre-commit hooks

* Remove useless noqas with hook

* Fix all single rst backticks

* Simplify mypy pre-commit hook with upstream fixes

* Add back missing comment

* Add one last pygrep hook

docs/advanced/classes.rst

@@ -1266,7 +1266,7 @@ Custom type setup
 =================
 
 For advanced use cases, such as enabling garbage collection support, you may
-wish to directly manipulate the `PyHeapTypeObject` corresponding to a
+wish to directly manipulate the ``PyHeapTypeObject`` corresponding to a
 ``py::class_`` definition.
 
 You can do that using ``py::custom_type_setup``:

docs/advanced/embedding.rst

@@ -40,15 +40,15 @@ The essential structure of the ``main.cpp`` file looks like this:
     }
 
 The interpreter must be initialized before using any Python API, which includes
-all the functions and classes in pybind11. The RAII guard class `scoped_interpreter`
+all the functions and classes in pybind11. The RAII guard class ``scoped_interpreter``
 takes care of the interpreter lifetime. After the guard is destroyed, the interpreter
 shuts down and clears its memory. No Python functions can be called after this.
 
 Executing Python code
 =====================
 
-There are a few different ways to run Python code. One option is to use `eval`,
-`exec` or `eval_file`, as explained in :ref:`eval`. Here is a quick example in
+There are a few different ways to run Python code. One option is to use ``eval``,
+``exec`` or ``eval_file``, as explained in :ref:`eval`. Here is a quick example in
 the context of an executable with an embedded interpreter:
 
 .. code-block:: cpp
@@ -108,7 +108,7 @@ The two approaches can also be combined:
 Importing modules
 =================
 
-Python modules can be imported using `module_::import()`:
+Python modules can be imported using ``module_::import()``:
 
 .. code-block:: cpp
 
@@ -134,7 +134,7 @@ embedding the interpreter. This makes it easy to import local Python files:
     int n = result.cast<int>();
     assert(n == 3);
 
-Modules can be reloaded using `module_::reload()` if the source is modified e.g.
+Modules can be reloaded using ``module_::reload()`` if the source is modified e.g.
 by an external process. This can be useful in scenarios where the application
 imports a user defined data processing script which needs to be updated after
 changes by the user. Note that this function does not reload modules recursively.
@@ -144,7 +144,7 @@ changes by the user. Note that this function does not reload modules recursively
 Adding embedded modules
 =======================
 
-Embedded binary modules can be added using the `PYBIND11_EMBEDDED_MODULE` macro.
+Embedded binary modules can be added using the ``PYBIND11_EMBEDDED_MODULE`` macro.
 Note that the definition must be placed at global scope. They can be imported
 like any other module.
 
@@ -170,7 +170,7 @@ like any other module.
 
 Unlike extension modules where only a single binary module can be created, on
 the embedded side an unlimited number of modules can be added using multiple
-`PYBIND11_EMBEDDED_MODULE` definitions (as long as they have unique names).
+``PYBIND11_EMBEDDED_MODULE`` definitions (as long as they have unique names).
 
 These modules are added to Python's list of builtins, so they can also be
 imported in pure Python files loaded by the interpreter. Everything interacts
@@ -216,9 +216,9 @@ naturally:
 Interpreter lifetime
 ====================
 
-The Python interpreter shuts down when `scoped_interpreter` is destroyed. After
+The Python interpreter shuts down when ``scoped_interpreter`` is destroyed. After
 this, creating a new instance will restart the interpreter. Alternatively, the
-`initialize_interpreter` / `finalize_interpreter` pair of functions can be used
+``initialize_interpreter`` / ``finalize_interpreter`` pair of functions can be used
 to directly set the state at any time.
 
 Modules created with pybind11 can be safely re-initialized after the interpreter
@@ -230,8 +230,8 @@ global data. All the details can be found in the CPython documentation.
 
 .. warning::
 
-    Creating two concurrent `scoped_interpreter` guards is a fatal error. So is
-    calling `initialize_interpreter` for a second time after the interpreter
+    Creating two concurrent ``scoped_interpreter`` guards is a fatal error. So is
+    calling ``initialize_interpreter`` for a second time after the interpreter
     has already been initialized.
 
     Do not use the raw CPython API functions ``Py_Initialize`` and
@@ -242,7 +242,7 @@ global data. All the details can be found in the CPython documentation.
 Sub-interpreter support
 =======================
 
-Creating multiple copies of `scoped_interpreter` is not possible because it
+Creating multiple copies of ``scoped_interpreter`` is not possible because it
 represents the main Python interpreter. Sub-interpreters are something different
 and they do permit the existence of multiple interpreters. This is an advanced
 feature of the CPython API and should be handled with care. pybind11 does not
@@ -258,5 +258,5 @@ We'll just mention a couple of caveats the sub-interpreters support in pybind11:
  2. Managing multiple threads, multiple interpreters and the GIL can be
     challenging and there are several caveats here, even within the pure
     CPython API (please refer to the Python docs for details). As for
-    pybind11, keep in mind that `gil_scoped_release` and `gil_scoped_acquire`
+    pybind11, keep in mind that ``gil_scoped_release`` and ``gil_scoped_acquire``
     do not take sub-interpreters into account.

docs/advanced/exceptions.rst

@@ -96,18 +96,18 @@ A matching function is available for registering a local exception translator:
 
 
 It is possible to specify base class for the exception using the third
-parameter, a `handle`:
+parameter, a ``handle``:
 
 .. code-block:: cpp
 
     py::register_exception<CppExp>(module, "PyExp", PyExc_RuntimeError);
     py::register_local_exception<CppExp>(module, "PyExp", PyExc_RuntimeError);
 
-Then `PyExp` can be caught both as `PyExp` and `RuntimeError`.
+Then ``PyExp`` can be caught both as ``PyExp`` and ``RuntimeError``.
 
 The class objects of the built-in Python exceptions are listed in the Python
 documentation on `Standard Exceptions <https://docs.python.org/3/c-api/exceptions.html#standard-exceptions>`_.
-The default base class is `PyExc_Exception`.
+The default base class is ``PyExc_Exception``.
 
 When more advanced exception translation is needed, the functions
 ``py::register_exception_translator(translator)`` and

docs/advanced/functions.rst

@@ -232,7 +232,7 @@ is equivalent to the following pseudocode:
     });
 
 The only requirement is that ``T`` is default-constructible, but otherwise any
-scope guard will work. This is very useful in combination with `gil_scoped_release`.
+scope guard will work. This is very useful in combination with ``gil_scoped_release``.
 See :ref:`gil`.
 
 Multiple guards can also be specified as ``py::call_guard<T1, T2, T3...>``. The

docs/advanced/misc.rst

@@ -84,7 +84,7 @@ could be realized as follows (important changes highlighted):
         });
     }
 
-The ``call_go`` wrapper can also be simplified using the `call_guard` policy
+The ``call_go`` wrapper can also be simplified using the ``call_guard`` policy
 (see :ref:`call_policies`) which yields the same result:
 
 .. code-block:: cpp

docs/advanced/pycpp/utilities.rst

@@ -28,7 +28,7 @@ Capturing standard output from ostream
 
 Often, a library will use the streams ``std::cout`` and ``std::cerr`` to print,
 but this does not play well with Python's standard ``sys.stdout`` and ``sys.stderr``
-redirection. Replacing a library's printing with `py::print <print>` may not
+redirection. Replacing a library's printing with ``py::print <print>`` may not
 be feasible. This can be fixed using a guard around the library function that
 redirects output to the corresponding Python streams:
 
@@ -62,9 +62,9 @@ This method respects flushes on the output streams and will flush if needed
 when the scoped guard is destroyed. This allows the output to be redirected in
 real time, such as to a Jupyter notebook. The two arguments, the C++ stream and
 the Python output, are optional, and default to standard output if not given. An
-extra type, `py::scoped_estream_redirect <scoped_estream_redirect>`, is identical
+extra type, ``py::scoped_estream_redirect <scoped_estream_redirect>``, is identical
 except for defaulting to ``std::cerr`` and ``sys.stderr``; this can be useful with
-`py::call_guard`, which allows multiple items, but uses the default constructor:
+``py::call_guard``, which allows multiple items, but uses the default constructor:
 
 .. code-block:: cpp
 
@@ -74,7 +74,7 @@ except for defaulting to ``std::cerr`` and ``sys.stderr``; this can be useful wi
                          py::scoped_estream_redirect>());
 
 The redirection can also be done in Python with the addition of a context
-manager, using the `py::add_ostream_redirect() <add_ostream_redirect>` function:
+manager, using the ``py::add_ostream_redirect() <add_ostream_redirect>`` function:
 
 .. code-block:: cpp
 
@@ -103,7 +103,7 @@ arguments to disable one of the streams if needed.
 Evaluating Python expressions from strings and files
 ====================================================
 
-pybind11 provides the `eval`, `exec` and `eval_file` functions to evaluate
+pybind11 provides the ``eval``, ``exec`` and ``eval_file`` functions to evaluate
 Python expressions and statements. The following example illustrates how they
 can be used.