You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Make all deprecation messages use the warnings.warn function.
Right now we use two different ways, some deprecation messages use logging.warning and some are using warnings.warn.
There was some discussion about using logging or warnings module for deprecation. In the Python world, warnings module is the most use way to do deprecation. Here are some arguments that where taken into account when deciding to use warnings module over logging:
When running normal (python manage.py runserver 0.0.0.0:8000)
Logging deprecations ARE printed (every time they appear)
Warnings deprecations are NOT printed.
When deprecation warnings enabled (python -Wd manage.py runserver 0.0.0.0:8000)
Logging deprecations ARE printed. (every time they appear)
Warnings deprecations ARE printed. (only printed ONCE, the first time it is emmited.)
When running tests (pytest ...)
Logging deprecations ARE printed (when the test fails)
Warnings deprecations ARE printed.
Tests DO NOT FAIL!
When running tests and treating errors as warnings (pytest -W error) This is what we are doing in sentry repo.
Logging deprecations ARE printed (when the test fails)
Logging deprecations are NOT breaking the test run.
Warnings deprecations ARE printed.
Warnings deprecations ARE breaking the test run.
Deprecation warnings from certain packages can be ignored by adding this to pytest.ini:
filterwarnings =
error ; turn warnings into errors; ignore::DeprecationWarning:polls.* ; if users call deprecated sentry function from their code they also need to ignore depreactions from their module
ignore::DeprecationWarning:sentry_sdk.* ; ignore deprecations from sentry_sdk
All in all:
warnings are not shown in the default case (which is good, we do not want to annoy users)
warnings are only emitted once (compared to logging, where every call will be logged, so warnings do not spam the users logs that much
warnings are printed by default when running tests. This is OK.
There is fine grained settings for showing/hiding warnings and also a lot of tooling supports warnings.
The text was updated successfully, but these errors were encountered:
Make all deprecation messages use the
warnings.warn
function.Right now we use two different ways, some deprecation messages use
logging.warning
and some are usingwarnings.warn
.There was some discussion about using
logging
orwarnings
module for deprecation. In the Python world,warnings
module is the most use way to do deprecation. Here are some arguments that where taken into account when deciding to usewarnings
module overlogging
:When running normal (
python manage.py runserver 0.0.0.0:8000
)When deprecation warnings enabled (
python -Wd manage.py runserver 0.0.0.0:8000
)When running tests (
pytest ...
)When running tests and treating errors as warnings (
pytest -W error
) This is what we are doing insentry
repo.All in all:
warnings
are not shown in the default case (which is good, we do not want to annoy users)warnings
are only emitted once (compared to logging, where every call will be logged, so warnings do not spam the users logs that muchwarnings
are printed by default when running tests. This is OK.warnings
and also a lot of tooling supportswarnings
.The text was updated successfully, but these errors were encountered: