Nick Coghlan <ncogh...@gmail.com> added the comment:
Reviewing the original thread yet again, you're right the original decision
wasn't specifically about developer tools (and I guess at some level I knew
that, or I wouldn't have been motivated to suggest the change to
FutureWarning's documented purpose).
That said, I consider noise from developer tools to be the most compelling
example as:
1. Running them from the command line is their normal mode of use (unlike GUI
apps which often have no visible console, implicitly silencing all warnings
anyway)
2. It's routine for Python developers to run their developer tools on the
latest version of Python, whereas regular applications are more likely to be
pre-tested against a particular Python version these days
3. Mixing up warnings from a tool like pylint or mypy about the code it is
analysing with deprecation warnings about pylint's own code is clearly going to
be unhelpful and confusing, no matter how you feel about deprecation warnings
in the general case
All the points that are most debatable for regular apps ("Do they even have a
console?", "Why are end users supplying their own Python version?", "Why can't
they just ignore the error?") have clear answers in the developer tools case
that favour leaving deprecation warnings off by default.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31975>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
