gh-90953: Emit deprecation warnings for ast features deprecated in Python 3.8

[AlexWaygood]

This is a continuation of @serhiy-storchaka's PR #31432, but removes the deprecation warnings for ast.ExtSlice and ast.Index, which were only deprecated in Python 3.9 (rationale for excluding them: #31432 (comment)).

• Issue: ast.Constant.n deprecated without warning #90953

---

📚 Documentation preview 📚: https://cpython-previews--104199.org.readthedocs.build/

[hugovk]

Nice :)

By the way, https://github.com/isidentical/teyit / https://pypi.org/project/teyit/ is a nice tool that can upgrade some of these automatically.

[barneygale]

Is it necessary to emit deprecation warnings when the names are accessed on the ast module? Would it not be sufficient to emit warnings when these classes are instantiated (+ isinstance etc)?

[AlexWaygood]

Is it necessary to emit deprecation warnings when the names are accessed on the ast module? Would it not be sufficient to emit warnings when these classes are instantiated (+ isinstance etc)?

I guess I lean towards keeping them just to ensure maximum visibility. There are edge cases where you might not be "using" the class or calling isinstance() on it, but you do reference it (if type(blah) is ast.Num, etc.). But you are right that we could probably simplify the code somewhat if we only warned on instantiation and isinstance() checks.

@hugovk, do you have any thoughts on this?

[hugovk]

If there are two common ways of accessing something, I'd also lean towards more visibility for both.

Speaking from a position of having dealt with the fallout of removing something without a DeprecationWarning first, just mentioning in docs :)

[AlexWaygood]

Thanks very much, both of you!

[iritkatriel]

@AlexWaygood Is it time to make the PR to remove them now?

[AlexWaygood]

@AlexWaygood Is it time to make the PR to remove them now?

yes

[AlexWaygood]

@AlexWaygood Is it time to make the PR to remove them now?

See #119563