Document 3.13, 3.14, 4.0 and future removals by hugovk · Pull Request #93986 · python/cpython
I wonder if there was some automation we can add to help ensure that planned deprecations actually happen? Like, maybe a JSON file or some such where the deprecations are recorded (or a script to parse the docs or code). Then, when the new version is created at main, the automation would open some release blockers on those deprecations. What do you think?
@warsaw Probably, grepping docs for .. deprecated-removed:: and headers for Py_DEPRECATED would be better than maintaining another list file.
Edit: for \.\. deprecated-removed:: [^ ]+ (\d+).(\d+) and Py_DEPRECATED\((\d+).(\d+)\).
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left a comment and a couple of minor suggestions -- feel free to disregard them if you think the current version is better.
Co-authored-by: Ezio Melotti <ezio.melotti@gmail.com>
I wonder if there was some automation we can add to help ensure that planned deprecations actually happen?
You could also fire a Sphinx warning in the else branch here in the directive (with a check for whether its an alpha, and perhaps an :option: to disable it for special cases), just like warnings._deprecated does.
Co-authored-by: Ezio Melotti <ezio.melotti@gmail.com>
| :keyword:`for`, :keyword:`if`, :keyword:`in`, :keyword:`is` and :keyword:`or`. | ||
| In a future release it will be changed to a syntax error. (:gh:`87999`) | ||
|
|
||
| * :func:`asyncio.get_event_loop` emits a :exc:`DeprecationWarning` if there is |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The deprecation plans for this function have changed. See #100970 for the updated deprecation notice.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the note! This PR has got pretty out of date...
Will try again in a new PR :)
