Changes between Initial Version and Version 1 of Ticket #21188
- Timestamp:
- Sep 28, 2013, 7:45:35 AM (11 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #21188 – Description
initial v1 11 11 By using these warnings we can achieve the following: 12 12 - Moving PendingDeprecationWarning to DeprecationWarning after release is single line change. 13 - It will be possible to filter on Django's deprecation warnings without ca ching warnings from non-django components.13 - It will be possible to filter on Django's deprecation warnings without catching warnings from non-django components. 14 14 - 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. 15 15 - 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. … … 18 18 Drawbacks: 19 19 - If we use automatic filtering for deprecations, then code currently doing: 20 warning.simplefilter("always", DeprecationWarning) 21 will no longer catch Django's deprecation warnings (as we added an entry for warning.simplefilter("default" ToBeRemovedInDjango18Warning)which matches before DeprecationWarning.20 `warning.simplefilter("always", DeprecationWarning)` 21 will no longer catch Django's deprecation warnings (as we added an entry for `warning.simplefilter("default" ToBeRemovedInDjango18Warning)` which matches before DeprecationWarning. 22 22 23 23 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".