pywikibot includes a lot of deprecation methods and parameters to support old code. The deprecation messages are logged using the normal python logging system, but are not routed through warnings.DeprecationWarning, which allows command line control over whether they are displayed (and defaults to not being displayed)
https://docs.python.org/2/library/warnings.html#warnings.warn
Version: core-(2.0)
Severity: major
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=71738
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Use warnings for deprecation | pywikibot/core | master | +510 -193 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Invalid | None | T72936 Important tasks to be solved (tracking) | |||
| Resolved | jayvdb | T72970 use DeprecationWarning system |
The deprecation notices are too noisy - users with custom scripts get scared when their screen is full of repetitive warnings.
For me, I prefer to see repetitive warnings which indicate that I should fix my script. Also, I strongly disagree that warning should not be displayed by default. The purpose of warning is to let users know explicitly. If something needs not to show to users, then switch to .debug instead (which will only show in verbose mode).
Change 187106 had a related patch set uploaded (by John Vandenberg):
Use warnings for deprecation
The warnings system allows individuals to select how many warnings they want to see. we could add a config option to assist.
Yeah it seems sensible that -verbose should enable this. Another problem is actually, that the logging levels are now don't make sense anymore. There is a WARNING level which is always shown and there are warnings which aren't shown by default.
are you referring to the tools warnings shown on travis? I believe that is a separate problem relating to how some tests are run before 'bot' initialisation. There are ui_tests for warning, but they probably dont check that warnings are not shown if the logging subsystem is set at error level.
With regards to warnings.warn we should be setting the warnings filters to honour the config settings. The warnings regarding config are subclasses of UserWarning, which are shown by default. Currently, the warnings about config problems were using 'print' and thus were previously always shown (i.e. they were not warnings) . The warnings regarding arguments will likely change a bit when we move to argparse, so we should consider that in the implementation of warnings.