Changes between Initial Version and Version 3 of Ticket #25999


Ignore:
Timestamp:
01/14/16 01:10:47 (7 years ago)
Author:
Tim Graham
Comment:

PR

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #25999

    • Property Status changed from new to assigned
    • Property Component changed from Documentation to Core (Other)
    • Property Summary changed from Document why Django makes its deprecation warnings loud by default and how to silence them to Remove making deprecation warnings loud by default
    • Property Owner changed from nobody to Tim Graham
    • Property Has patch set
  • Ticket #25999 – Description

    initial v3  
    11See #18985 for the background of why we route warnings through logging.
    22
    3 A developer can selectively silence warnings using something like this in an app's `AppConfig.ready()` method:
    4 {{{
    5 import warnings
    6 from django.utils.deprecation import RemovedInNextVersionWarning
    7 warnings.simplefilter("ignore", RemovedInNextVersionWarning)
    8 }}}
    9 This example can be improved to show how to silence a particular warning instead of all warnings.
     3However, this idea is slightly flawed given our current deprecation scheme. If a third-party library wants to support both 1.8 and 1.11 (next LTS) would have to use a try (new import)/except (old import) pattern to avoid code running on 1.11 from raising deprecation warnings (some pending deprecation in 1.10, deprecated in 1.11, and removed in 2.0). In my mind, part of the purpose of the new policy was to avoid this type of complexity.
    104
    11 This works because `AppConfig.ready()` methods are called after `django.utils.log.configure_logging()` (which does `warnings.simplefilter("default", RemovedInNextVersionWarning)`) in `django.setup()`.
     5For that reason, I think we should reconsider making Django's deprecation warnings loud by default (at least in LTS versions). Otherwise, users will pester library authors to fix those warnings and we haven't really made things easier.
     6
     7Instead, the idea would be for library authors to continue using the deprecated APIs while supporting the LTS in which they are deprecated and the previous LTS. When the version of Django following the LTS is released, library authors can then drop support for all Django versions before the LTS, check their package with the LTS using python -Wd and make the deprecation warning fixes, then seamlessly add support for the next version of Django.
Back to Top