gh-95913: Copyedit, link & format Typing Features section in 3.11 What's New (GH-96097)

Co-authored-by: Ezio Melotti <[email protected]>
Co-authored-by: Alex Waygood <[email protected]>

Author: 3 people

Doc/whatsnew/3.11.rst

@@ -208,22 +208,28 @@ PEP written by Zac Hatfield-Dodds.)
 
 
 .. _new-feat-related-type-hints-311:
+.. _whatsnew311-typing-features:
 
 New Features Related to Type Hints
 ==================================
 
 This section covers major changes affecting :pep:`484` type hints and
 the :mod:`typing` module.
 
+
+.. _whatsnew311-pep646:
+
 PEP 646: Variadic generics
 --------------------------
 
-:pep:`484` introduced :data:`~typing.TypeVar`, enabling creation
-of generics parameterised with a single type. :pep:`646` introduces
+:pep:`484` previously introduced :data:`~typing.TypeVar`, enabling creation
+of generics parameterised with a single type. :pep:`646` adds
 :data:`~typing.TypeVarTuple`, enabling parameterisation
 with an *arbitrary* number of types. In other words,
 a :data:`~typing.TypeVarTuple` is a *variadic* type variable,
-enabling *variadic* generics. This enables a wide variety of use cases.
+enabling *variadic* generics.
+
+This enables a wide variety of use cases.
 In particular, it allows the type of array-like structures
 in numerical computing libraries such as NumPy and TensorFlow to be
 parameterised with the array *shape*. Static type checkers will now
@@ -235,26 +241,30 @@ See :pep:`646` for more details.
 Serhiy Storchaka and Jelle Zijlstra. PEP written by Mark Mendoza, Matthew
 Rahtz, Pradeep Kumar Srinivasan, and Vincent Siles.)
 
+
+.. _whatsnew311-pep655:
+
 PEP 655: Marking individual ``TypedDict`` items as required or not-required
 ---------------------------------------------------------------------------
 
 :data:`~typing.Required` and :data:`~typing.NotRequired` provide a
 straightforward way to mark whether individual items in a
-:data:`~typing.TypedDict` must be present. Previously this was only possible
+:class:`~typing.TypedDict` must be present. Previously, this was only possible
 using inheritance.
 
-Fields are still required by default, unless the ``total=False``
-parameter is set.
-For example, the following specifies a dictionary with one required and
-one not-required key::
+All fields are still required by default,
+unless the *total* parameter is set to ``False``,
+in which case all fields are still not-required by default.
+For example, the following specifies a :class:`!TypedDict`
+with one required and one not-required key::
 
    class Movie(TypedDict):
       title: str
       year: NotRequired[int]
 
-   m1: Movie = {"title": "Black Panther", "year": 2018}  # ok
-   m2: Movie = {"title": "Star Wars"}  # ok (year is not required)
-   m3: Movie = {"year": 2022}  # error (missing required field title)
+   m1: Movie = {"title": "Black Panther", "year": 2018}  # OK
+   m2: Movie = {"title": "Star Wars"}  # OK (year is not required)
+   m3: Movie = {"year": 2022}  # ERROR (missing required field title)
 
 The following definition is equivalent::
 
@@ -267,15 +277,20 @@ See :pep:`655` for more details.
 (Contributed by David Foster and Jelle Zijlstra in :issue:`47087`. PEP
 written by David Foster.)
 
+
+.. _whatsnew311-pep673:
+
 PEP 673: ``Self`` type
 ----------------------
 
 The new :data:`~typing.Self` annotation provides a simple and intuitive
 way to annotate methods that return an instance of their class. This
-behaves the same as the :data:`~typing.TypeVar`-based approach specified
-in :pep:`484` but is more concise and easier to follow.
+behaves the same as the :class:`~typing.TypeVar`-based approach
+:pep:`specified in PEP 484 <484#annotating-instance-and-class-methods>`,
+but is more concise and easier to follow.
 
-Common use cases include alternative constructors provided as classmethods
+Common use cases include alternative constructors provided as
+:func:`classmethod <classmethod>`\s,
 and :meth:`~object.__enter__` methods that return ``self``::
 
    class MyLock:
@@ -300,6 +315,9 @@ See :pep:`673` for more details.
 (Contributed by James Hilton-Balfe in :issue:`46534`. PEP written by
 Pradeep Kumar Srinivasan and James Hilton-Balfe.)
 
+
+.. _whatsnew311-pep675:
+
 PEP 675: Arbitrary literal string type
 --------------------------------------
 
@@ -334,14 +352,17 @@ See :pep:`675` for more details.
 (Contributed by Jelle Zijlstra in :issue:`47088`. PEP written by Pradeep
 Kumar Srinivasan and Graham Bleaney.)
 
+
+.. _whatsnew311-pep681:
+
 PEP 681: Data Class Transforms
 ------------------------------
 
 :data:`~typing.dataclass_transform` may be used to
 decorate a class, metaclass, or a function that is itself a decorator.
 The presence of ``@dataclass_transform()`` tells a static type checker that the
-decorated object performs runtime "magic" that
-transforms a class, giving it :func:`dataclasses.dataclass`-like behaviors.
+decorated object performs runtime "magic" that transforms a class,
+giving it :func:`dataclass <dataclasses.dataclass>`-like behaviors.
 
 For example::
 
@@ -353,26 +374,32 @@ For example::
         cls.__ne__ = ...
         return cls
 
-    # The create_model decorator can now be used to create new model
-    # classes, like this:
+    # The create_model decorator can now be used to create new model classes:
     @create_model
     class CustomerModel:
         id: int
         name: str
 
-    c = CustomerModel(id=327, name="John Smith")
+    c = CustomerModel(id=327, name="Eric Idle")
 
 See :pep:`681` for more details.
 
 (Contributed by Jelle Zijlstra in :gh:`91860`. PEP written by
 Erik De Bonte and Eric Traut.)
 
-PEP 563 May Not Be the Future
+
+.. _whatsnew311-pep563-deferred:
+
+PEP 563 may not be the future
 -----------------------------
 
-* :pep:`563` Postponed Evaluation of Annotations, ``__future__.annotations``
-  that was planned for this release has been indefinitely postponed.
-  See `this message <https://mail.python.org/archives/list/[email protected]/message/VIZEBX5EYMSYIJNDBF6DMUMZOCWHARSO/>`_ for more information.
+:pep:`563` Postponed Evaluation of Annotations
+(the ``from __future__ import annotations`` :ref:`future statement <future>`)
+that was originally planned for release in Python 3.10
+has been put on hold indefinitely.
+See `this message from the Steering Council <https://mail.python.org/archives/list/[email protected]/message/VIZEBX5EYMSYIJNDBF6DMUMZOCWHARSO/>`__
+for more information.
+
 
 Windows py.exe launcher improvements
 ------------------------------------