On 8 November 2017 at 03:55, Barry Warsaw <ba...@python.org> wrote: > On Nov 7, 2017, at 05:44, Paul Moore <p.f.mo...@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. a GUI application) - with enough deprecation warnings the stderr buffer could become full and block, preventing the application from progressing. I've just had a similar issue where a process was running as a service and used subprocess.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, but with mechanisms or recommendations for the application developer to silence them selectively for the current release. Tim Delaney
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com