On 8 November 2017 at 03:55, Barry Warsaw <barry@python.org> wrote:

On Nov 7, 2017, at 05:44, Paul Moore <p.f.moore@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