Message307726
| Author |
ncoghlan |
| Recipients |
ncoghlan, vstinner |
| Date |
2017年12月06日.11:12:24 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1512558744.84.0.213398074469.issue32231@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
I'm hesitant to put the *true* default filters in sys.warnoptions, as folks use "bool(sys.warnoptions)" as a check for "Were any warning options set via the environment or the command line?", and we don't want to invalidate that use case.
However, I'm definitely a fan of having the warnings module *only* look at sys.warnoptions, and requiring *all* command line options to route their filter settings through that channel.
https://bugs.python.org/issue32230 adjusts "-X dev" to work that way, and I'm suggesting we do the same here for "-b".
That way, we can fully define the relative ordering of PYTHONWARNINGS, "-X dev", "-W", and "-b" inside pymain_add_warnings_options (and only the true default filters will be appended by the warnings module itself). |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2017年12月06日 11:12:25 | ncoghlan | set | recipients:
+ ncoghlan, vstinner |
| 2017年12月06日 11:12:24 | ncoghlan | set | messageid: <1512558744.84.0.213398074469.issue32231@psf.upfronthosting.co.za> |
| 2017年12月06日 11:12:24 | ncoghlan | link | issue32231 messages |
| 2017年12月06日 11:12:24 | ncoghlan | create |
|