Reconcile discussion on how to approach the spec (#6)

python · JelleZijlstra · Oct 4, 2023 · Sep 23, 2023 · Sep 23, 2023 · Sep 23, 2023
commit 54e6bfb7f01b8e96db27b51bd63954d88db2c0c7
@@ -229,7 +229,7 @@ standardization.
 Specification for the type system
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-A specification could initially be created by stitching together the
+A specification would 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 was `created by Jelle <https://github.com/JelleZijlstra/typing-spec>`_.
@@ -253,11 +253,13 @@ are better served by a more informal user-facing reference, which is discussed
 in the next section.
 
 There are different opinions within the community about how formal such a
-specification should be. This document does not aim to resolve those
-disagreements, but it provides a process that would enable the creation of a
-spec at the community's desired level of formality.
+specification should be. While this document recommends an incremental
+approach that builds off existing specification, it does not aim to
+prescribe a final state. The Typing Council would provide a mechanism
+to allow the specification to evolve to meet the level of formality that
+the community desires, for instance, by incorporating parts of
 Kevin Millikin's `document on "Python Static Types" <https://docs.google.com/document/d/1mVCU-nVPT_zVfqivVdMY1aOOZqJ9lsgOLweO1U3uwUM/edit>`_
-could provide a basis for formalizing much of the spec.
+as a means to achieve a better formalisation of the spec.
 
 Proposed changes to the specification, including PEPs, should
 generally be accompanied by the following: