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 alex, barry, eric.araujo, gvanrossum, ncoghlan, pitrou, r.david.murray
Date 2017-11-09.07:04:05
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1510211046.25.0.213398074469.issue31975@psf.upfronthosting.co.za>
In-reply-to
Content
I'm currently still too annoyed to write a PEP about this - it would probably come out in tone like the state of the unicode literals PEP before I edited it.

I just don't understand how this logic is hard: *our* primary responsibility for deprecation warnings is to ensure that Python developers (including us) can alert other *Python developers* as to upcoming API breakages.

Yet somehow this primary goal has been subordinated to "app developers are bad at managing whether or not deprecation warnings are shown to their users, so it's OK that we ended up breaking deprecation warnings in general for everyone that doesn't run a test suite, even though we didn't realise that's what we were doing at the time we made the decision".

And I'll repeat: I'm entirely happy with the "revert the change for __main__ only" compromise, since it covers all the cases I care about.

If folks are also running third party single file scripts, and those scripts are emitting warnings, and they really hate seeing those warnings, then they can put "PYTHONWARNINGS=ignore::DeprecationWarning" into their shell profile.
History
Date User Action Args
2017-11-09 07:04:06ncoghlansetrecipients: + ncoghlan, gvanrossum, barry, pitrou, eric.araujo, alex, r.david.murray
2017-11-09 07:04:06ncoghlansetmessageid: <1510211046.25.0.213398074469.issue31975@psf.upfronthosting.co.za>
2017-11-09 07:04:06ncoghlanlinkissue31975 messages
2017-11-09 07:04:05ncoghlancreate