[Python-Dev] Proposal: go back to enabling DeprecationWarning by default

[Tim Delaney]

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. 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171108/afc01584/attachment.html>