From 12ae9eb0332de22ac6fb1e2c83baeba608722483 Mon Sep 17 00:00:00 2001 From: Carl Meyer Date: Wed, 12 Jun 2024 11:12:58 -0400 Subject: [PATCH] some review comments --- docs/spec/callables.rst | 4 ++-- docs/spec/class-compat.rst | 2 +- docs/spec/concepts.rst | 6 +++--- docs/spec/generics.rst | 2 +- docs/spec/literal.rst | 4 ++-- docs/spec/protocol.rst | 15 ++++++++------- 6 files changed, 17 insertions(+), 16 deletions(-) diff --git a/docs/spec/callables.rst b/docs/spec/callables.rst index bc9c5396..e86d0ea1 100644 --- a/docs/spec/callables.rst +++ b/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 diff --git a/docs/spec/class-compat.rst b/docs/spec/class-compat.rst index c1f47ffb..9f88d564 100644 --- a/docs/spec/class-compat.rst +++ b/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 diff --git a/docs/spec/concepts.rst b/docs/spec/concepts.rst index 0669e787..930385b0 100644 --- a/docs/spec/concepts.rst +++ b/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 diff --git a/docs/spec/generics.rst b/docs/spec/generics.rst index 93955775..3ae51c78 100644 --- a/docs/spec/generics.rst +++ b/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. :: diff --git a/docs/spec/literal.rst b/docs/spec/literal.rst index f9decdef..fa66b6ad 100644 --- a/docs/spec/literal.rst +++ b/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: ... diff --git a/docs/spec/protocol.rst b/docs/spec/protocol.rst index 71537150..8b30a7e1 100644 --- a/docs/spec/protocol.rst +++ b/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 ` 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**: