This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients barry, eric.snow, ncoghlan, vstinner
Date 2017-11-15.02:18:55
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
While it doesn't necessarily need to be in this patch, something else I recently realised (by breaking it *cough* [1]) is that the interaction between our command line options and our environment variables isn't really clearly defined anywhere. restored the handling of simple on/off toggles as "toggle enabled = env var is set OR CLI flag is passed", but I noticed the other day that the interaction between PYTHONWARNINGS, the `-W` option, sys.warnoptions, and _warnings.filters is a bit confusing:

$ PYTHONWARNINGS=always,default python3 -Wignore -Wonce
Python 3.6.2 (default, Oct  2 2017, 16:51:32) 
[GCC 7.2.1 20170915 (Red Hat 7.2.1-2)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys, _warnings
>>> sys.warnoptions
['always', 'default', 'ignore', 'once']
>>> [f[0] for f in _warnings.filters[:4]]
['once', 'ignore', 'default', 'always']

The ordering makes *sense* (where sys.warnoptions just lists filter definitions in the order they're given, and later filters take priority over earlier ones, just as they do for any "warnings.filterwarnings" call), but it isn't immediately intuitive (since the outcome relies on filters being prepended by default).

That said, I've checked and the current warnings configuration behaviour *is* explicitly covered by the test suite (in, so a passing test suite provides confidence we haven't broken anything on that front.

Date User Action Args
2017-11-15 02:18:56ncoghlansetrecipients: + ncoghlan, barry, vstinner, eric.snow
2017-11-15 02:18:56ncoghlansetmessageid: <>
2017-11-15 02:18:56ncoghlanlinkissue32030 messages
2017-11-15 02:18:55ncoghlancreate