Changes between Initial Version and Version 1 of Ticket #18985, comment 3


Ignore:
Timestamp:
Sep 18, 2012, 7:47:46 PM (12 years ago)
Author:
Donald Stufft

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #18985, comment 3

    initial v1  
    1 After discussion with ptone on IRC three points have been raised that a change to make DeprecationWarning loud again needs to hit these points: early, configurable, universal. My PR as it stands is early and configurable, but it's not universal (It doesn't touch WSGI, but more importantly it doesn't affect anyone who currently has a project without them manually adding it.)
     1After discussion with ptone on IRC three points have been raised that a change to make `DeprecationWarning` loud again needs to hit these points: early, configurable, universal. My PR as it stands is early and configurable, but it's not universal (It doesn't touch WSGI, but more importantly it doesn't affect anyone who currently has a project without them manually adding it.)
    22
    33The options as it stands to re-emit the warning are:
    … …  
    551. Add a filter to the default manage.py. This happens before any other code happens so it is the earliest entry point. It also is easily configurable as it is included in the users project code. However this is the least universal as it will only affect new projects created in 1.5 unless developers of existing projects add the same code to their manage.py
    66
    7 2. Add a filter someplace early on in Django. This will be less early than the manage.py solution, but it should be early enough to catch all the warnings. This is also universal, any users of Django 1.5 will get this change without needing to make any changes to their project. This one falls down at the configurable stage, without either providing another settings value (or possibly keying it off of DEBUG?) there would not be a way for a developer to silence this warning without directly modifying Django. While it's true that the majority of projects do not have end users that would be affected by the DeprecationWarning display it's likely that there are at least some of them and this change would remove the developers ability to silence them.
     72. Add a filter someplace early on in Django. This will be less early than the manage.py solution, but it should be early enough to catch all the warnings. This is also universal, any users of Django 1.5 will get this change without needing to make any changes to their project. This one falls down at the configurable stage, without either providing another settings value (or possibly keying it off of DEBUG?) there would not be a way for a developer to silence this warning without directly modifying Django. While it's true that the majority of projects do not have end users that would be affected by the `DeprecationWarning` display it's likely that there are at least some of them and this change would remove the developers ability to silence them.
    88
    9 3. Add a filter someplace early on in Django, but turn on ``logging.captureWarnings`` so that all the warnings get redirected to a named logger called ``py.warnings`` with a level of ``WARNING``. This would likely need to have the default LOGGING configuration changed to output ``py.warnings`` to STDOUT (or STDERR). This solution would be early and configurable, and it would also be universal as long as the project in question has a logging configuration that would result in messages sent to ``py.warnings`` with level ``WARNING`` to be emitted. If, for example, they have a root logger configured this would be sufficient.
     93. Add a filter someplace early on in Django, but turn on `logging.captureWarnings` so that all the warnings get redirected to a named logger called `py.warnings` with a level of `WARNING`. This would likely need to have the default LOGGING configuration changed to output `py.warnings` to STDOUT (or STDERR). This solution would be early and configurable, and it would also be universal as long as the project in question has a logging configuration that would result in messages sent to `py.warnings` with level `WARNING` to be emitted. If, for example, they have a root logger configured this would be sufficient.
Back to Top