regret 2024.2.2

Deprecations

regret can deprecate:

• [x] callables

  • [x] functions

  • [x] classes

    • [ ] subclassable classes

• [ ] attributes

  • [ ] of modules

  • [ ] of classes (& methods)

  • [ ] of instances

• [ ] descriptors

  • [ ] classmethod

• [ ] modules

  • [ ] current module

  • [ ] other module

• [ ] parameters to callables

  • [x] previously required parameters that will be removed

  • [x] optional parameters that are now required

  • [ ] deprecated values for parameters

  • [ ] type changes for parameters

  • [ ] mutual exclusion

• [ ] interfaces

  • [ ] PEP 544 protocols

  • [ ] zope.interfaces

• [x] inheritability of a class

Design Goals

regret is meant to cover all of the deprecations an author may encounter.

It is intended to:

• be versioning system agnostic (i.e. SemVer, CalVer, HipsTer, etc.), because deprecations originate from a version, a point in time, or both.

• be documentation system aware (i.e. Sphinx, epydoc, Plaintext, etc.), because deprecations need communication.

• be itself fully tested, because deprecations must not break the code they deprecate

• support removal date indication, and likely “policies” which automate choosing default removal dates, because deprecations ultimately intend some ultimate change

• make “clean code” trivially easy to deprecate, and make complex code possible to deprecate, because the deprecation process is fraught with edge cases and unforeseen necessity.

• minimize the amount of deprecation-related code required for authors, since deprecations are boring, and we all want to focus on developing our libraries instead.

In particular, as a lofty first milestone, it is intended to cover all of the specific deprecations required for these jsonschema issues, and with luck, to subsume all the functionality present in twisted.python.deprecate.