You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Schedule removal for deprecated abc decorators #149609
changed the title [-]Remove deprecated abc.abstractclassmethod, etc for 3.16[/-][+]Remove deprecated `abc.abstractclassmethod`, etc for 3.16[/+]on May 9, 2026
changed the title [-]Remove deprecated `abc.abstractclassmethod`, etc for 3.16[/-][+]Schedule removal for deprecated `abc` decorators[/+]on May 9, 2026
I haven't worked on the abc module at all, but my general view is that removing things is always costly as it can break libraries and make it harder for people to upgrade. These functions are marked as @deprecated in typeshed, so IDEs should already avoid suggesting them.
Unfortunately, they are still allowed in the suggestion list, but I guess it's more a problem for the IDE to solve. Do we have a policy on adding runtime warnings for deprecated functions actually? because those functions were only deprecated in docs.
If we want to remove them, we need runtime warnings first. ("For changes that are unable to raise a deprecation warning, consult with the steering council.")
Warnings should be raised for a minimum of two feature releases, but five years is preferred:
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).
Activity
[-]Remove deprecated abc.abstractclassmethod, etc for 3.16[/-][+]Remove deprecated `abc.abstractclassmethod`, etc for 3.16[/+]picnixz commentedon May 9, 2026
picnixz commentedon May 9, 2026
Oh wait, there was no warning? so no we can't remove them sorry.
picnixz commentedon May 9, 2026
They've been deprecated since 3.3. If we plan to deprecate them (warning+removal) we need a 5y period first now.
[-]Remove deprecated `abc.abstractclassmethod`, etc for 3.16[/-][+]Schedule removal for deprecated `abc` decorators[/+]picnixz commentedon May 9, 2026
cc @JelleZijlstra @sobolevn @hugovk @rhettinger
aiwonderland commentedon May 9, 2026
JelleZijlstra commentedon May 10, 2026
I haven't worked on the abc module at all, but my general view is that removing things is always costly as it can break libraries and make it harder for people to upgrade. These functions are marked as
@deprecatedin typeshed, so IDEs should already avoid suggesting them.picnixz commentedon May 10, 2026
Unfortunately, they are still allowed in the suggestion list, but I guess it's more a problem for the IDE to solve. Do we have a policy on adding runtime warnings for deprecated functions actually? because those functions were only deprecated in docs.
hugovk commentedon May 10, 2026
Yes, PEP 387.
If we want to remove them, we need runtime warnings first. ("For changes that are unable to raise a deprecation warning, consult with the steering council.")
Warnings should be raised for a minimum of two feature releases, but five years is preferred:
https://peps.python.org/pep-0387/#making-incompatible-changes
pythongh-149609: Raise deprecation warnings for `abc.{abstractclassme…
gh-149609: Raise deprecation warnings for `abc.{abstractclassmethod,a…