some review comments

docs/spec/callables.rst

@@ -1,4 +1,4 @@
-.. _`callables`:
+`.. _`callables`:
 
 Callables
 =========
@@ -530,7 +530,7 @@ interchangeably.
 Assignability rules for callables
 ---------------------------------
 
-A callable type ``B`` is :term:`assignable` to callable type ``A`` if the
+A callable type ``B`` is :term:`assignable` to a callable type ``A`` if the
 return type of ``B`` is assignable to the return type of ``A`` and the input
 signature of ``B`` accepts all possible combinations of arguments that the
 input signature of ``A`` accepts. All of the specific assignability rules

docs/spec/class-compat.rst

@@ -99,7 +99,7 @@ annotated in ``__init__`` or other methods, rather than in the class::
 When type checkers encounter a method decorated with ``@typing.override`` they
 should treat it as a type error unless that method is overriding a method or
 attribute in some ancestor class, and the type of the overriding method is
-assignable to the type of the overridden method.
+:term:`assignable` to the type of the overridden method.
 
 
 .. code-block:: python

docs/spec/concepts.rst

@@ -253,9 +253,9 @@ Summary of type relations
 
 The subtype, supertype, and equivalence relations establish a partial order on
 fully static types. The analogous relations on gradual types (via
-materialization) are "assignable-to" (or consistent subtype), "assignable-from"
-(or consistent supertype), and "consistent with". We can visualize this analogy
-in the following table:
+materialization) are "assignable-to" (or "consistent subtype"),
+"assignable-from" (or "consistent supertype"), and "consistent with". We can
+visualize this analogy in the following table:
 
 .. list-table::
    :header-rows: 1

docs/spec/generics.rst

@@ -2266,7 +2266,7 @@ Use in Attribute Annotations
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Another use for ``Self`` is to annotate attributes. One example is where we
-have a ``LinkedList`` whose elements must be consistent subtypes of the current
+have a ``LinkedList`` whose elements must be :term:`assignable` to the current
 class.
 
 ::

docs/spec/literal.rst

@@ -303,8 +303,8 @@ special-casing. For example, programs like the following are type safe::
    # Legal: Literal["foo"] is a subtype of str
    expects_str(var)
 
-This also means non-Literal types in general are not assignable to Literal
-types. For example::
+This also means non-Literal types in general are not :term:`assignable` to
+Literal types. For example::
 
    def expects_literal(x: Literal["foo"]) -> None: ...
 

docs/spec/protocol.rst

@@ -29,11 +29,12 @@ attributes and methods, it is said to implement the protocol and to be
 assignable to the protocol. If a class is assignable to a protocol but the
 protocol is not included in the MRO, the class is *implicitly* assignable to
 the protocol. (Note that one can explicitly subclass a protocol and still not
-implement it if a protocol attribute is set to ``None`` in the subclass, see
+implement it if a protocol attribute is set to ``None`` in the subclass. See
 Python :py:ref:`data model <specialnames>` for details.)
 
 The attributes (variables and methods) of a protocol that are mandatory for
-another class to be assignable to the protocol are called protocol members.
+another class for it to be assignable to the protocol are called "protocol
+members".
 
 .. _protocol-definition:
 
@@ -75,7 +76,7 @@ be used in every context where normal types can::
 
 Note that both the user-defined class ``Resource`` and the built-in ``IO`` type
 (the return type of ``open()``) are assignable to ``SupportsClose``, because
-they provide a ``close()`` method with an assignable type signature.
+each provides a ``close()`` method with an assignable type signature.
 
 
 Protocol members
@@ -621,10 +622,10 @@ the risks for this feature, the following rules are applied.
   ``Iterator``, etc). A protocol that contains at least one non-method member
   (like ``x: int``) is called a data protocol.
 * *Unsafe overlap*: A type ``X`` is called unsafely overlapping with a protocol
-  ``P``, if ``X`` is not assignable to ``P``, but it is assignable to the type
-  erased version of ``P`` where all members have type ``Any``. In addition, if
-  at least one element of a union unsafely overlaps with a protocol ``P``, then
-  the whole union is unsafely overlapping with ``P``.
+  ``P``, if ``X`` is not assignable to ``P``, but it is assignable to the
+  type-erased version of ``P`` where all members have type ``Any``. In
+  addition, if at least one element of a union unsafely overlaps with a
+  protocol ``P``, then the whole union is unsafely overlapping with ``P``.
 
 **Specification**: