Apply suggestions from code review

Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
Co-authored-by: Carl Meyer <carl@oddbird.net>

Author: 3 people

peps/pep-9999.rst

@@ -6,8 +6,8 @@ Discussions-To: <REQUIRED: URL of current canonical discussion thread>
 Status: Draft
 Type: Standards Track
 Topic: Typing
-Created: ?-Nov-2024
-Python-Version: 3.?
+Created: 18-Nov-2024
+Python-Version: 3.14
 
 
 Abstract
@@ -20,14 +20,14 @@ This PEP proposes expanding the scope of ``ReadOnly`` to class and protocol
 attributes, as a single concise way to mark them read-only. Some parity changes
 are also made to :data:`typing.Final`.
 
-Akin to :pep:`705`, it makes no Python grammar changes. Correct usage of
+Akin to :pep:`705`, it makes no changes to setting attributes at runtime. Correct usage of
 read-only attributes is intended to be enforced only by static type checkers.
 
 
 Motivation
 ==========
 
-Python type system lacks a single concise way to mark an :term:`attribute` read-only.
+The Python type system lacks a single concise way to mark an :term:`attribute` read-only.
 This feature is common in other object-oriented languages (such as `C# <https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/readonly>`_),
 and is useful for restricting attribute mutation at a type checker level, as well
 as defining a broad interface for structural subtyping.
@@ -37,7 +37,7 @@ as defining a broad interface for structural subtyping.
 Classes
 -------
 
-There are 3 major ways of achieving read-only attributes, honored by type checkers:
+Today, there are three major ways of achieving read-only attributes, honored by type checkers:
 
 * annotating the attribute with :data:`typing.Final`::
 
@@ -54,7 +54,7 @@ There are 3 major ways of achieving read-only attributes, honored by type checke
 
   - Supported by :mod:`dataclasses` (and type checkers since `typing#1669 <https://github.com/python/typing/pull/1669>`_).
   - Overriding ``number`` is not possible - the specification of ``Final``
-    imposes the name cannot be overridden in subclasses.
+    imposes that the name cannot be overridden in subclasses.
 
 * read-only proxy via ``@property``::
 
@@ -97,10 +97,10 @@ Protocols
 ---------
 
 Paraphrasing `this post <https://github.com/python/typing/discussions/1525>`_,
-there is no way of defining a :class:`~typing.Protocol`, such that the only
+there is no way of defining an attribute ``name: T`` on a :class:`~typing.Protocol`, such that the only
 requirements to satisfy are:
 
-1. ``hasattr(obj, name)``
+1. ``hasattr(obj, "name")``
 2. ``isinstance(obj.name, T)`` [#invalid_typevar]_
 
 The above are satisfiable at runtime by all of the following:
@@ -135,9 +135,9 @@ Rationale
 
 These problems can be resolved by an attribute-level :external+typing:term:`type qualifier`.
 ``ReadOnly`` has been chosen for this role, as its name conveys the intent well,
-and the newly proposed changes complement its semantics defined in the :pep:`705`.
+and the newly proposed changes complement its semantics defined in :pep:`705`.
 
-A class with a read-only instance attribute can be now defined as such::
+A class with a read-only instance attribute can now be defined as::
 
     from typing import ReadOnly
 
@@ -146,7 +146,7 @@ A class with a read-only instance attribute can be now defined as such::
         def __init__(self, id: int) -> None:
             self.id: ReadOnly = id
 
-...and a protocol described in :ref:`protocols` is now just::
+...and the protocol described in :ref:`protocols` is now just::
 
     from typing import Protocol, ReadOnly
 
@@ -170,10 +170,10 @@ Specification
 
 The :external+py3.13:data:`typing.ReadOnly` :external+typing:term:`type qualifier`
 becomes a valid annotation for :term:`attributes <attribute>` of classes and protocols.
-It is used to indicate that an attribute should not be reassigned or ``del``\ eted.
+Type checkers should error on any attempt to reassign or ``del``\ ete an attribute annotated with ``ReadOnly``.
 
-The deletability rule should be extended to ``Final`` as well, as it is currently
-not specified.
+Type checkers should also error on any attempt to delete an attribute annotated as ``Final``.
+(This is not currently specified.)
 
 Akin to ``Final``, read-only attributes do not influence the mutability of
 the assigned object. Immutable ABCs and containers may be used in combination with
@@ -198,8 +198,8 @@ The explicit type in ``ReadOnly[<type>]`` can be omitted if the declaration has
 an initializing value. A type checker should apply its usual type inference
 rules to determine the type of ``name``.
 
-If an attribute is already implied to be read-only, like in the frozen :ref:`classes`,
-explicit declarations should be permitted and seen as equivalent, except ``Final``
+If an attribute is already implied to be read-only, like in frozen :ref:`classes`,
+explicit declarations should be permitted and seen as equivalent, except that ``Final``
 additionally forbids overriding in subclasses:
 
 .. code-block:: python
@@ -364,7 +364,7 @@ Borrowing from :pep:`PEP 705 <705#inheritance>`:
             print(self.foo, self.bar, self.baz)
 
 * In a protocol attribute declaration, ``name: ReadOnly[T]`` indicates that a structural
-  subtype must support ``.name`` access, and the returned value is compatible with ``T``::
+  subtype must support ``.name`` access, and the returned value is assignable to ``T``::
 
     class HasName(Protocol):
         name: ReadOnly[str]
@@ -496,7 +496,7 @@ Extending initialization
 Mechanisms such as :func:`dataclasses.__post_init__` or attrs' `initialization hooks <https://www.attrs.org/en/stable/init.html#hooking-yourself-into-initialization>`_
 augment initialization by providing a set of dunder hooks which will be called
 once during instance creation. The current rules would disallow assignment in those
-hooks. Specifying any single method in the pep isn't enough, as the naming and
+hooks. Specifying any single method in the PEP isn't enough, as the naming and
 functionality differs between mechanisms (``__post_init__`` vs ``__attrs_post_init__``).
 
 ``ReadOnly[ClassVar[...]]`` and ``__init_subclass__``