# PEP 700: Additional Fields for the Simple API for Package Indexes

**URL:** <https://discuss.python.org/t/pep-700-additional-fields-for-the-simple-api-for-package-indexes/20177>\
**Category:** Packaging\
**Created:** [October 21, 2022, 11:42am UTC](https://discuss.python.org/t/pep-700-additional-fields-for-the-simple-api-for-package-indexes/20177 "2022-10-21T11:42:43Z")\
**Posts on this page:** 1\
**Showing post:** 26

<div class="post-metadata">

**Author:** ![pradyunsg](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pradyunsg/32/206_2.png) [@pradyunsg](https://discuss.python.org/u/pradyunsg)\
**Post date:** [November 2, 2022, 4:26am UTC](https://discuss.python.org/t/pep-700-additional-fields-for-the-simple-api-for-package-indexes/20177/26 "2022-11-02T04:26:03Z")

</div>

> [@dustin](#):
>
> This makes me wonder whether instead of some kind of major/minor versioning, we should provide a field with the PEP numbers the API supports, something like:
> 
> ```auto
> ...
> 'supports': [691, 700]
> 
> ```

FWIW, if we do go this route, it’d be friendlier IMO to use some sort of legible names for the features instead (eg: `upload-times`, `versions`) rather than using numbers instead. Besides, 691 is implied. 🙂

See also [Consider renaming this project to not include the PEP number · Issue #10 · FFY00/python-pyproject-metadata · GitHub](https://github.com/FFY00/python-pyproject-metadata/issues/10), [Rename `pep517` to `pyproject-hooks`, and trim functionality · Issue #136 · pypa/pyproject-hooks · GitHub](https://github.com/pypa/pyproject-hooks/issues/136) and [Name for pyproject.toml builds and PEPs](https://discuss.python.org/t/name-for-pyproject-toml-builds-and-peps/1659) about not using PEP numbers for user-facing functional pieces (yes, this is a format detail but still – similar argues apply since the consumers are written by people 😉).

---

_[View the full topic](https://discuss.python.org/t/pep-700-additional-fields-for-the-simple-api-for-package-indexes/20177)._