PEP 729 suggestions (python#4)

peps/pep-0729.rst

@@ -21,7 +21,7 @@ Motivation
 ==========
 
 The Python type system was created by :pep:`484`, now almost ten years ago. The type
-system has been a great success, and typing has become an important tool for writing
+system is now widely used, and typing has become an important tool for writing
 good, maintainable Python code. Many changes have been made to the type system to cover
 more use cases and improve usability. Several type checkers have been created, each
 with their own strengths. The type annotation syntax has driven several major innovations
@@ -79,6 +79,9 @@ Some concrete examples include:
   type system features. Type checkers are expected to treat symbols in this
   module the same as symbols in :mod:`typing`, but this is not explicitly
   specified in any of the PEPs.
+* Various semantics are informally agreed upon by type checkers, but not
+  documented anywhere, for example, `variable initialization <https://mail.python.org/archives/list/[email protected]/thread/GYVM5KEE6URE6PAH7UTK6324M7GWSFQS/#SY3KPJCAW4UTOOCH3XRJYROSGDEGOTWI>`_
+  or `symbol visibility <https://mail.python.org/archives/list/[email protected]/thread/YLJPWECBNPD2K4TRIBRIPISNUZJCRREY/#OX4GLBQOOCMRE5YPZEY3R3XNV6DD7XLW>`_
 
 The type system is underspecified
 ---------------------------------
@@ -96,7 +99,7 @@ The Steering Council is not well-placed to solve the above problems
 -------------------------------------------------------------------
 
 The SC has the entire language in its remit, and is not well-placed to make
-decisions that are purely about the type system —- if only because they don't have
+decisions that are purely about the type system -- if only because they don't have
 the time to deal with type system arcana alongside their other responsibilities.
 This is similar in spirit to the reasons why the Steering Council sometimes uses
 PEP delegation.
@@ -128,7 +131,8 @@ The Typing Council's mandate is to ensure that the Python type system is:
   should be ergonomic to write well-typed Python code that is accepted by type
   checkers. There should be good documentation for the type system.
 * **Stable**: As the type system matures, users should be able to rely on their
-  typed code continuing to work. Changes should be made with care and in a way
+  typed code continuing to work and be able to trust their mental model for the
+  type system. Changes should be made with care and in a way
   that minimizes disruption. Nevertheless, the type system should be able to
   evolve, and type checkers need not be held to the same strict compatibility
   standards as the Python language itself.
@@ -224,7 +228,7 @@ Specification for the type system
 A specification could initially be created by stitching together the
 specification sections from the existing PEPs, and then gradually improved to
 clarify points of confusion and cover more areas. A draft of such a
-stitched-together spec `exists <https://github.com/JelleZijlstra/typing-spec>`_.
+stitched-together spec was `created by Jelle <https://github.com/JelleZijlstra/typing-spec>`_.
 
 The specification has a few audiences: