[Django] #25999: Document why Django makes its deprecation warnings loud by default and how to silence them
Django
to silence them
------------------------------------------------+------------------------
Reporter: timgraham | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Documentation | Version: master
Severity: Normal | Keywords:
Triage Stage: Accepted | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
------------------------------------------------+------------------------
See #18985 for the background of why we route warnings through logging.
A developer can selectively silence warnings using something like this in
an app's `AppConfig.ready()` method:
{{{
import warnings
from django.utils.deprecation import RemovedInNextVersionWarning
warnings.simplefilter("ignore", RemovedInNextVersionWarning)
}}}
This example can be improved to show how to silence a particular warning
instead of all warnings.
This works because `AppConfig.ready()` methods are called after
`django.utils.log.configure_logging()` (which does
`warnings.simplefilter("default", RemovedInNextVersionWarning)`) in
`django.setup()`.
--
Ticket URL: <https://code.djangoproject.com/ticket/25999>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
to silence them
Reporter: timgraham | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Documentation | Version: master
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by timgraham):
I [https://groups.google.com/d/msg/django-
developers/ZWy2Esj46nE/DEv8O1znDwAJ raised a proposal] to discontinue
making RemovedInNextVersionWarning loud by default.
--
Ticket URL: <https://code.djangoproject.com/ticket/25999#comment:1>
Django
-------------------------------------+-------------------------------------
Reporter: timgraham | Owner: timgraham
Type: | Status: assigned
Cleanup/optimization |
Component: Core (Other) | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* owner: nobody => timgraham
* status: new => assigned
* component: Documentation => Core (Other)
--
Ticket URL: <https://code.djangoproject.com/ticket/25999#comment:2>
Django
-------------------------------------+-------------------------------------
Reporter: timgraham | Owner: timgraham
Type: | Status: assigned
Cleanup/optimization |
Component: Core (Other) | Version: master
Severity: Normal | Resolution:
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* has_patch: 0 => 1
Old description:
> See #18985 for the background of why we route warnings through logging.
>
> A developer can selectively silence warnings using something like this in
> an app's `AppConfig.ready()` method:
> {{{
> import warnings
> from django.utils.deprecation import RemovedInNextVersionWarning
> warnings.simplefilter("ignore", RemovedInNextVersionWarning)
> }}}
> This example can be improved to show how to silence a particular warning
> instead of all warnings.
>
> This works because `AppConfig.ready()` methods are called after
> `django.utils.log.configure_logging()` (which does
> `warnings.simplefilter("default", RemovedInNextVersionWarning)`) in
> `django.setup()`.
New description:
See #18985 for the background of why we route warnings through logging.
However, 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.
For 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.
Instead, 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.
--
Comment:
[https://github.com/django/django/pull/5979 PR]
--
Ticket URL: <https://code.djangoproject.com/ticket/25999#comment:3>
Django
-------------------------------------+-------------------------------------
Reporter: timgraham | Owner: timgraham
Type: | Status: assigned
Cleanup/optimization |
Component: Core (Other) | Version: master
Severity: Normal | Resolution:
| checkin
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by claudep):
* stage: Accepted => Ready for checkin
Comment:
I'm a bit torn by this issue. I understand the current policy is making
things complex for 3-party apps to prevent warnings. On another side, I
always considered prominent deprecation warnings as a feature of Django,
as it helps so much to keep clean up-to-date code in your project. Let's
educate developers to think a bit more about `-Wall`!
--
Ticket URL: <https://code.djangoproject.com/ticket/25999#comment:4>
Django
-------------------------------------+-------------------------------------
Reporter: timgraham | Owner: timgraham
Cleanup/optimization |
Component: Core (Other) | Version: master
Keywords: | Triage Stage: Ready for
| checkin
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham <timograham@…>):
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"5b94b17feff15a9f0345f92fc0568bfe7038e3a3" 5b94b17f]:
{{{
#!CommitTicketReference repository=""
revision="5b94b17feff15a9f0345f92fc0568bfe7038e3a3"
Fixed #25999 -- Removed promotion of RemovedInNextVersionWarning to loud
by default.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/25999#comment:5>
Django
-------------------------------------+-------------------------------------
Reporter: Tim Graham | Owner: Tim
Type: | Graham
Cleanup/optimization | Status: closed
Component: Core (Other) | Version: master
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Ready for
| checkin
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Tim Graham <timograham@…>):
In [changeset:"4bb70cbcc60794f515c9bfefeca87b8272d33c0c" 4bb70cb]:
{{{
#!CommitTicketReference repository=""
revision="4bb70cbcc60794f515c9bfefeca87b8272d33c0c"
Removed an obsolete (as of refs #25999) logging test from refs #18985.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/25999#comment:6>