Improve cross referencing in documentation

coredis/pipeline.py

@@ -1156,6 +1156,10 @@ async def execute(self, raise_on_error: bool = True) -> Tuple[object, ...]:
  return await self.__wrapped__.execute(raise_on_error=raise_on_error)
 
  async def reset(self) -> None:
+ """
+ Resets the command stack and releases any connections acquired from the
+ pool
+ """
  await self.__wrapped__.reset_pipeline()
 
 
@@ -1222,4 +1226,8 @@ async def execute(self, raise_on_error: bool = True) -> Tuple[object, ...]:
  return await self.__wrapped__.execute(raise_on_error=raise_on_error)
 
  def reset(self) -> None:
+ """
+ Resets the command stack and releases any connections acquired from the
+ pool
+ """
  self.__wrapped__.reset_pipeline()

docs/source/conf.py

@@ -88,6 +88,7 @@
  "https://raw.githubusercontent.com/redis/redis/%s/00-RELEASENOTES",
  "Redis version: %s",
  ),
+ "command": ("https://redis.io/commands/%s", "%s"),
 }
 
 

docs/source/handbook/cluster.rst

@@ -30,11 +30,11 @@ Examples of such APIs are:
 Replication
 ^^^^^^^^^^^
 
-**coredis** supports ensuring synchronous replication of writes using the ``WAIT``
+**coredis** supports ensuring synchronous replication of writes using the :command:`WAIT`
 command. This is abstracted away with the :meth:`~coredis.RedisCluster.ensure_replication`
 context manager.
 
-The following example will ensure that the ``SET`` is replicated to atleast 2 replicas within 100 milliseconds (default
+The following example will ensure that the :command:`SET` is replicated to atleast 2 replicas within 100 milliseconds (default
 value of :paramref:`~coredis.RedisCluster.ensure_replication.timeout_ms`),
 else raise a :exc:`~coredis.exceptions.ReplicationError`::
 

docs/source/handbook/noreply.rst

@@ -5,7 +5,7 @@ For scenarios where the response from the redis server is not relevant
 to the client the :paramref:`~coredis.Redis.noreply` parameter can be passed to
 either the :class:`~coredis.Redis` or :class:`~coredis.RedisCluster` constructors
 which ensures the client does not wait for responses from the server and additionally
-sets ``CLIENT REPLY OFF`` for any connection used by the client. This can provide some
+sets ``CLIENT REPLY OFF`` (using the :command:`CLIENT-REPLY` command) for any connection used by the client. This can provide some
 performance benefits.
 
 For example::

docs/source/handbook/pipelines.rst

@@ -52,18 +52,18 @@ off transactions.
 
 A common issue occurs when requiring atomic transactions but needing to
 retrieve values in Redis prior for use within the transaction. For instance,
-let's assume that the INCR command didn't exist and we need to build an atomic
-version of ``INCR`` in Python.
+let's assume that the :command:`INCR` command didn't exist and we need to build an atomic
+version of :command:`INCR` in Python.
 
-The completely naive implementation could GET the value, increment it in
-Python, and ``SET`` the new value back. However, this is not atomic because
+The completely naive implementation could :command:`GET` the value, increment it in
+Python, and :command:`SET` the new value back. However, this is not atomic because
 multiple clients could be doing this at the same time, each getting the same
-value from ``GET``.
+value from :command:`GET`.
 
-Enter the ``WATCH`` command. ``WATCH`` provides the ability to monitor one or more keys
+Enter the :command:`WATCH` command. :command:`WATCH` provides the ability to monitor one or more keys
 prior to starting a transaction. If any of those keys change prior the
 execution of that transaction, the entire transaction will be canceled and a
-WatchError will be raised. To implement our own client-side INCR command, we
+WatchError will be raised. To implement our own client-side :command:`INCR` command, we
 could do something like this:
 
 .. code-block:: python
@@ -94,11 +94,11 @@ could do something like this:
  continue
 
 Note that, because the Pipeline must bind to a single connection for the
-duration of a WATCH, care must be taken to ensure that the connection is
-returned to the connection pool by calling the reset() method. If the
-Pipeline is used as a context manager (as in the example above) :meth:`~coredis.Pipeline.reset`
+duration of a :command:`WATCH`, care must be taken to ensure that the connection is
+returned to the connection pool by calling the :meth:`~coredis.pipeline.Pipeline.reset` method. If the
+:class:`~coredis.pipeline.Pipeline` is used as a context manager (as in the example above) :meth:`~coredis.pipeline.Pipeline.reset`
 will be called automatically. Of course you can do this the manual way by
-explicitly calling :meth:`~coredis.Pipeline.reset`:
+explicitly calling :meth:`~coredis.pipeline.Pipeline.reset`:
 
 .. code-block:: python
 
@@ -115,10 +115,10 @@ explicitly calling :meth:`~coredis.Pipeline.reset`:
  finally:
  await pipe.reset()
 
-A convenience method :meth:`coredis.Redis.transaction` exists for handling all the
+A convenience method :meth:`~coredis.Redis.transaction` exists for handling all the
 boilerplate of handling and retrying watch errors. It takes a callable that
 should expect a single parameter, a pipeline object, and any number of keys to
-be ``WATCH``ed. Our client-side ``INCR`` command above can be written like this,
+be watched. Our client-side :command:`INCR` command above can be written like this,
 which is much easier to read:
 
 .. code-block:: python

docs/source/handbook/scripting.rst

@@ -3,7 +3,7 @@ Scripting
 
 LUA Scripts
 ^^^^^^^^^^^
-coredis supports the ``EVAL``, ``EVALSHA``, and ``SCRIPT`` commands. However, there are
+coredis supports the :command:`EVAL`, :command:`EVALSHA`, and :command:`SCRIPT` commands. However, there are
 a number of edge cases that make these commands tedious to use in real world
 scenarios. Therefore, coredis exposes a :class:`~coredis.commands.Script`
 class that makes scripting much easier to use.
@@ -33,7 +33,7 @@ invoked by calling it like a function. Script instances accept the following opt
 * **args**: A list of argument values. This becomes the ARGV list in LUA.
 * **client**: A coredis Client or Pipeline instance that will invoke the
  script. If client isn't specified, the client that initially
- created the Script instance (the one that `register_script` was
+ created the :class:`coredis.commands.Script` instance (the one that :meth:`~coredis.Redis.register_script` was
  invoked from) will be used.
 
 Continuing the example from above:

docs/source/handbook/typing.rst

@@ -6,8 +6,8 @@ Type Annotations
 **coredis** provides type annotations for the public API. These are tested using
 both :pypi:`mypy` and :pypi:`pyright`.
 
-The :class:`Redis` and :class:`RedisCluster` clients are Generic types constrained
-by :class:`AnyStr`. The constructors and ``from_url`` factory methods infer
+The :class:`~coredis.Redis` and :class:`~coredis.RedisCluster` clients are Generic types constrained
+by :class:`AnyStr`. The constructors and :meth:`~coredis.Redis.from_url` factory methods infer
 the appropriate specialization automatically.
 
 Without decoding: