Remove deprecated `ast` nodes sooner

[Andrej730]

Feature or enhancement

Proposal:

#140345 added a warning for use of deprecated ast nodes:

cpython/Doc/deprecations/pending-removal-in-3.21.rst

Lines 13 to 19 in a7bb524

	* :mod:`ast`:
	* Classes ``slice``, ``Index``, ``ExtSlice``, ``Suite``, ``Param``,
	``AugLoad`` and ``AugStore``, will be removed in Python 3.21. These types
	are not generated by the parser or accepted by the code generator.
	* The ``dims`` property of ``ast.Tuple`` will be removed in Python 3.21. Use
	the ``ast.Tuple.elts`` property instead.

I've noticed that by warning coming from typeshed and it was odd to see something appearing deprecated since 3.9 still existing.

https://github.com/python/typeshed/blob/0be0f58382c5fad1ea79fca495d68afd5fa8b7ee/stdlib/ast.pyi#L1225-L1227

The problem is, even after warning added, removal is targeting 3.21, which is a bit far a way, 2032. It was chosen using default deprecation period from PEP387 (ref):

Making an incompatible change is a gradual process performed over several releases:

• Wait for the warning to appear in at least two minor Python versions of the same major version, or one minor version in an older major version (e.g., for a warning in Python 3.10.0, you either wait until at least Python 3.12 or Python 4.0 to make the change). It is preferred, though, to wait 5 years before removal (e.g., warn starting in Python 3.10, removal in 3.15; this happens to coincide with the current lifetime of a minor release of Python).

But given that those were deprecated since 3.9, 6 years ago, we definitely can switch to 3.18 - PEP387 also allows warning to appear for just two minor versions.

Or maybe it's possible to remove it in 3.17, after one year of warnings? Given that by then it will be 8 versions of deprecation and we also we'll be able to include this deprecation warning with information about 3.17 removal to typeshed, so users will get notified about this sooner than 3.16 release (at least the ones using type checkers).

If it helps, type checkers users were also notified since 2024 - python/typeshed#13285 (though only possibly, given that deprecated warning support might be missing in some type checkers at that time).

Happy to submit a PR to cpython and then typeshed, if there's consensus to retarget it to 3.17 / 3.18.

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

No response

[hugovk]

#140345 added a warning in 3.16, so 3.18 is the absolute minimum for removal, and 3.21 is recommended.

What's the motivation for rushing removal? Other than it has been deprecated via docs since 3.9, but people rarely pay attention to docs-only deprecations, and a fair number also don't pay attention to runtime warnings.

[Andrej730]

Nothing breaks if we remove them later - it just seems deprecation period wasn't explicitly discussed in the PR that added warnings and it seems these symbols can reasonably be cleaned up earlier than 12 years since they were deprecated.

5 year deprecation period is probably needed when symbols were the standard way to do something as recently as the prior Python version, but in this case we've already had 6 years when it's not true - new code was written not considering those nodes, possibly triggering a rewrite of the old code, + the linter warnings mentioned before.

Also they weren't just docs deprecated - visit_Index (and other methods) had no effect since Python 3.9, there was no fallback. Same for isinstance(subscript.slice, ast.Index) (always-False).
The use of those nodes during the deprecation period is probably either dead code (in some cases resulting in errors if post Python 3.9 state of ast wasn't considered) or aliases for constructing other nodes - e.g. ExtSlice() results in a Tuple, Index(value) in a value.

Regarding other classes - Suite was removed because it was already unused (#83820). Param, AugLoad, AugStore were never exposed to the users, they never occur in Python 3, users might have used it only for isinstance checks to cover Python 2 (#84169).

But does everyone agree that targeting removal at 3.18 sounds okay for this?