Machine-readable Specification for Deprecated and Removed APIs of CPython

Thank you for pinging me Hugo.

There was a lot of nuance in the first thread that are not present here in the status (with only deprecated / removed). Soft deprecation was added in PEP 387 PEP 387: Add Soft Deprecation section (#3182) · python/peps@57b1d94 · GitHub. Some talked about “discouraged usage” (something “better” – according to some – exists but the old thing is not going away, like for getopt), or “obsolete” (no longer recommended?).

Two deprecation warnings exists, but I’m not sure that it’s equivalent to soft/hard deprecation:

It’s probably better to at least go for “soft deprecation” / “hard deprecation” / “removed” in the status, maybe more options.

Also “replacement”, should be “replacements” and allow for a list of values (Formalize the concept of "soft deprecation" (don't schedule removal) in PEP 387 "Backwards Compatibility Policy" - #82 by brettcannon) I like the idea of having an URL to explain how to migrate when “replacements” is not easy to fill.

3 Likes