Author pitrou
Recipients alex, barry, eric.araujo, gvanrossum, ncoghlan, pitrou, r.david.murray
Date 2017-11-11.11:27:27
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <7855dfdf-b312-dbe3-e6b5-74a621151dfa@free.fr>
In-reply-to <1510369354.46.0.213398074469.issue31975@psf.upfronthosting.co.za>
Content
> * Recommend that test runners also set this in the environment (so it's inherited by subprocesses), not just in the current process

+1

> * Clearly document "-We", "-Wi", "-Wd" as shorthands to override the default warnings filters with universal "error", "ignore" and "default" settings (right now you have to reverse engineer this from the warnings docs)

+1

> * Clearly document "PYTHONWARNINGS=error", "PYTHONWARNINGS=ignore", and "PYTHONWARNINGS=default" as the environmental equivalents (right now you have to reverse engineer this from the warnings docs)

+1

> * Explicitly recommend FutureWarning as the "always visible by default" alternative to DeprecationWarning

That's rather weird.  It seems more and more library authors are
discontent with DeprecationWarning's default behaviour.  Why not change
DeprecationWarning's behaviour to match expectations instead of starting
recommending people switch to something less obvious?

> I suspect if we'd been clearer about our assumptions back when the change was made and advertised in the Python 2.7 What's New, we'd have had fewer problems in the time since

I think the main reason is that our assumptions weren't clear at all.
The people who promoted this change didn't envision the issues that
would come with it.
History
Date User Action Args
2017-11-11 11:27:28pitrousetrecipients: + pitrou, gvanrossum, barry, ncoghlan, eric.araujo, alex, r.david.murray
2017-11-11 11:27:28pitroulinkissue31975 messages
2017-11-11 11:27:27pitroucreate