[3.13] Doc: Simplify the definition of 'soft deprecated' (GH-124988) (#125029)

Doc: Simplify the definition of 'soft deprecated' (GH-124988)
(cherry picked from commit feca4cf64e)

Co-authored-by: Andrés Delfino <adelfino@gmail.com>
Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>
Co-authored-by: Sergey B Kirpichev <skirpichev@gmail.com>
Co-authored-by: Carol Willing <carolcode@willingconsulting.com>
This commit is contained in:
Miss Islington (bot) 2024-10-07 01:04:43 +02:00 committed by GitHub
parent b30da225cf
commit d7e4c790ff
No known key found for this signature in database
GPG key ID: B5690EEEBB952194

View file

@ -1150,16 +1150,12 @@ Glossary
(subscript) notation uses :class:`slice` objects internally.
soft deprecated
A soft deprecation can be used when using an API which should no longer
be used to write new code, but it remains safe to continue using it in
existing code. The API remains documented and tested, but will not be
developed further (no enhancement).
A soft deprecated API should not be used in new code,
but it is safe for already existing code to use it.
The API remains documented and tested, but will not be enhanced further.
The main difference between a "soft" and a (regular) "hard" deprecation
is that the soft deprecation does not imply scheduling the removal of the
deprecated API.
Another difference is that a soft deprecation does not issue a warning.
Soft deprecation, unlike normal deprecation, does not plan on removing the API
and will not emit warnings.
See `PEP 387: Soft Deprecation
<https://peps.python.org/pep-0387/#soft-deprecation>`_.