Movatterモバイル変換
[0]ホーム
[Python-Dev] Proposal: go back to enabling DeprecationWarning by default
Tim Delaneytimothy.c.delaney at gmail.com
Tue Nov 7 16:08:51 EST 2017
On 8 November 2017 at 03:55, Barry Warsaw <barry at python.org> wrote:> On Nov 7, 2017, at 05:44, Paul Moore <p.f.moore at gmail.com> wrote:>> > If you're a user and your application developer didn't do (1) or a> > library developer developing one of the libraries your application> > developer chose to use didn't do (2), you're hosed. If you're a user> > who works in an environment where moving to a new version of the> > application is administratively complex, you're hosed.>> “hosed” feels like too strong of a word here. DeprecationWarnings usually> don’t break anything. Sure, they’re annoying but they can usually be> easily ignored.>> Yes, there are some situations where DWs do actively break things (as I’ve> mentioned, some Debuntu build/test environments). But those are also> relatively easier to silence, or at least the folks running those> environments, or writing the code for those environments, are usually more> advanced developers for whom setting an environment variable or flag isn’t> that big of a deal.>One other case would be if you've got an application with no stderr (e.g. aGUI application) - with enough deprecation warnings the stderr buffer couldbecome full and block, preventing the application from progressing. I'vejust had a similar issue where a process was running as a service and usedsubprocess.check_output() - stderr was written to the parent's stderr,which didn't exist and caused the program to hang.However, I'm definitely +1 on enabling DeprecationWarning by default, butwith mechanisms or recommendations for the application developer to silencethem selectively for the current release.Tim Delaney-------------- next part --------------An HTML attachment was scrubbed...URL: <http://mail.python.org/pipermail/python-dev/attachments/20171108/afc01584/attachment.html>
More information about the Python-Devmailing list
[8]ページ先頭