Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gh-92308: Add a future pending removal #31

Closed
wants to merge 2 commits into from
Closed

gh-92308: Add a future pending removal #31

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
0e65516
Add a future pending removal
hugovk May 6, 2022
bcf1609
Edit future pending removal
hugovk May 6, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 17 additions & 0 deletions Doc/whatsnew/3.11.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1227,6 +1227,23 @@ C API:
* :c:type:`PyUnicodeObject`
* :c:func:`PyUnicode_InternImmortal()`

Pending Removal in Future Versions
==================================

The following APIs were deprecated in earlier Python versions and will be removed,
although there is currently no date scheduled for their removal.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure that it's a good idea of repeating this in each What's New in Python 3.x document. What if it's kept as "pending deprecated" for 10 versions? Should we copy/paste this text in 10 documents?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, the idea is to increase visibility of things to be removed.

We still want users to change their code for this, even if it's going to be around for a while.

A problem with deprecations is users don't know about them until removal, and sometimes long deprecation periods are to give folk more time to update. All the more reason to list them.

When we have a dedicated deprecations page, we could skip listing things here and instead link to the dedicated page. There's quite a few open-ended deprecations around, so it would also be useful for maintainers to review if they can be removed yet.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When we have a dedicated deprecations page, we could skip listing things here and instead link to the dedicated page.

If we want to automate the creation of the list/table, a dedicated page would be easier to handle, and won't have to necessarily conform to the structure of the whatsnew.

There's quite a few open-ended deprecations around

See python#92564


Python API:

* Currently Python accepts numeric literals immediately followed by keywords,
for example ``0in x``, ``1or x``, ``0if 1else 2``. It allows confusing
and ambiguous expressions like ``[0x1for x in y]`` (which can be
interpreted as ``[0x1 for x in y]`` or ``[0x1f or x in y]``).
A deprecation warning is raised if the numeric literal is
immediately followed by one of keywords :keyword:`and`, :keyword:`else`,
:keyword:`for`, :keyword:`if`, :keyword:`in`, :keyword:`is` and :keyword:`or`.
In future releases it will be changed to syntax warning, and finally to
syntax error.

Removed
=======
Expand Down