Documentation build overview

📚 cpython-previews | 🛠️ Build #32651162 | 📁 Comparing f32bf81 against main (a2c1657)

  🔍 Preview build  

Any reason to rush removal after the min two years instead of the recommended five?

Please also list in the relevant pending-removal-in-3.x.rst in https://github.com/python/cpython/tree/main/Doc/deprecations

Any reason to rush removal after the min two years instead of the recommended five?

I think it's because they've been deprecated since 3.3. But as I said, IDEs still pick them up in the suggestion list but they would show them as deprecated sometimes (it's more an IDE issue here).

I'm in favor of having a 5 years deprecation because those could be still used and I think we should let people know that they don't need this pattern anymore.

Any reason to rush removal after the min two years instead of the recommended five?

I think that this is not a rush :)
They were deprecated for a decade now, many tools already mark them this way. Inluding IDEs, type checkers and linters.
There are known bugs that we can help prevent by not using the deprecated version.
Plus, it is easy to switch to a pure stdlib alternative.

If others strongly believe that 5 years is a must, then I can make the change :(

Searching the top 15k PyPI projects (from February) found 632 matching lines in 150 projects for @(abc\.)?abstract(classmethod|staticmethod|property).

GitHub finds 26.9k files.

I also recommend opening issues for Ruff and pyupgrade to rewrite these deprecations (we should do this more often!).

I opened a new issue for ruff: astral-sh/ruff#25105
And rescheduled the removal to 3.21: a lot of packages rely on it :(