# PEP 771: Default Extras for Python Software Packages (Round 2) **URL:** \ **Category:** Standards\ **Created:** [June 9, 2025, 9:32am UTC](https://discuss.python.org/t/pep-771-default-extras-for-python-software-packages-round-2/94905 "2025-06-09T09:32:46Z")\ **Posts on this page:** 1\ **Showing post:** 12
**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:** [June 10, 2025, 11:43pm UTC](https://discuss.python.org/t/pep-771-default-extras-for-python-software-packages-round-2/94905/12 "2025-06-10T23:43:57Z")
> [@ncoghlan](#): > > So even though the term “extra” doesn’t currently appear in the _syntax_ of `pyproject.toml`, it _does_ appear in the existing specification. The only reason it doesn’t appear in the syntax is because that table is named after the _values_ it holds rather than after the keys. That’s… not quite the reasoning for that naming choice. [https://peps.python.org/pep-0621/#other-names-for-dependencies-optional-dependencies](https://peps.python.org/pep-0621/#other-names-for-dependencies-optional-dependencies) covers why this name was chosen. The underlying motivation here was that the “extras” terminology is unique to Python in a suboptimal way. Notably, I do think avoiding “using terminology that is necessarily foreign to new programmers” is a positive aspect of this that we’ve benefited from. I’ll also note that there’s significant and meaningful difference between the audience of who read a Python packaging standard’s specification vs the audience who uses the Python packaging standard. The fact that the specification uses certain terminology doesn’t necessarily endorse that we should use the same terminology in the user-facing surfaces. --- _[View the full topic](https://discuss.python.org/t/pep-771-default-extras-for-python-software-packages-round-2/94905)._