PEP691: Mark Accepted + Grammar Fixes + Small Fix (#2674)

pep-0691.rst

@@ -6,12 +6,13 @@ Author: Donald Stufft <[email protected]>,
         Dustin Ingram <[email protected]>
 PEP-Delegate: Brett Cannon <[email protected]>
 Discussions-To: https://discuss.python.org/t/pep-691-json-based-simple-api-for-python-package-indexes/15553
-Status: Draft
+Status: Accepted
 Type: Standards Track
 Topic: Packaging
 Content-Type: text/x-rst
 Created: 04-May-2022
 Post-History: `05-May-2022 <https://discuss.python.org/t/pep-691-json-based-simple-api-for-python-package-indexes/15553>`__
+Resolution: https://discuss.python.org/t/pep-691-json-based-simple-api-for-python-package-indexes/15553/70
 
 
 Abstract
@@ -519,7 +520,7 @@ human based exploration of the API within a browser, or to allow documentation o
 notes to link to a specific version+format.
 
 Servers that do not support this parameter may choose to return an error when it is
-present, or they may simple ignore it's presence.
+present, or they may simple ignore its presence.
 
 When a server does implement this parameter, it **SHOULD** take precedence over any
 values in the client's ``Accept`` header, and if the server does not support the
@@ -830,7 +831,7 @@ that static repositories will no longer be able to be hosted on GitHub Pages
 unless GitHub adds the ``application/vnd.pypi.simple.v1+json`` content type.
 
 This PEP believes that the benefits are not large enough to add that content
-type alias at this time, and that it's inclusion would likely be a footgun
+type alias at this time, and that its inclusion would likely be a footgun
 waiting for unsuspecting people to accidentally pick it up. Especially given
 that we can always add it in the future, but removing things is a lot harder
 to do.
@@ -941,13 +942,13 @@ Appendix 2: Rough Underlying Data Models
 ========================================
 
 These are not intended to perfectly match the server, client, or wire
-formats. Rather, these are concpetual models, put to code to make them
+formats. Rather, these are conceptual models, put to code to make them
 more explicit as to the abstract models underlining the repository API
 as it evolved through :pep:`503`, :pep:`529`, :pep:`629`, :pep:`658`,
 and now this PEP, :pep:`691`.
 
 The existing HTML, and the new JSON serialization of these models then
-represent how these underlying concpetual models get mapped onto the
+represent how these underlying conceptual models get mapped onto the
 actual wire formats.
 
 How servers or clients choose to model this data is out of scope for
@@ -982,6 +983,11 @@ this PEP.
     class PEP529File(File):
         yanked: bool | str
 
+    @dataclass
+    class PEP658File(PEP529File):
+        # Limited to a len() of 1 in HTML
+        dist_info_metadata: bool | dict[str, str]
+
 
     # Simple Index page (/simple/)
     @dataclass
@@ -1017,8 +1023,7 @@ this PEP.
 
     @dataclass
     class PEP658_Detail(PEP629_Detail):
-        # Limited to a len() of 1 in HTML
-        dist_info_metadata: bool | dict[str, str]
+      files: set[PEP658File]
 
 
     @dataclass