Use DeprecationWarning subclasses for deprecated features
|Reported by:||akaariai||Owned by:||nobody|
|Cc:||adi@…||Triage Stage:||Ready for checkin|
|Has patch:||yes||Needs documentation:||no|
|Needs tests:||no||Patch needs improvement:||no|
Description (last modified by timo)
The idea is to introduce new deprecation subclass for each Django version. For example, in current master:
class ToBeRemovedInDjango19Warning(PendingDeprecationWarning): pass class ToBeRemovedInDjango18Warning(DeprecationWarning): pass
By using these warnings we can achieve the following:
- Moving PendingDeprecationWarning to DeprecationWarning after release is single line change.
- It will be possible to filter on Django's deprecation warnings without catching warnings from non-django components.
- It will be harder to miss removal of code. After 1.7 is released just remove ToBeRemovedInDjango18Warning. Any code importing that warning will immediately fail. Also, grepping might be a little easier.
- After release, currently introducing a new PendingDeprecationWarning before PendingDeprecationWarnings are renamed to DeprecationWarnings (as part of release procedure) the new deprecatin will likely be moved to DeprecationWarning. But if a ToBeRemovedInDjango20Warning is added it will be really hard to accidentally move that one to DeprecationWarning.
- It will be technically easy to provide for longer than two releases deprecation periods (if we ever want this).
- If we use automatic filtering for deprecations, then code currently doing:
will no longer catch Django's deprecation warnings (as we added an entry for warning.simplefilter("default" ToBeRemovedInDjango18Warning) which matches before DeprecationWarning.
I tried this approach in: https://github.com/akaariai/django/compare/deprecation_subclasses#L3R18 - The patch is totally incomplete so I will not mark "has patch".
Change History (9)
comment:8 Changed 20 months ago by charettes
- Triage Stage changed from Accepted to Ready for checkin