Le 12/11/2017 à 00:41, Nick Coghlan a écrit :
> 
> Regarding "Why not revert DeprecationWarning to behaving the same as FutureWarning?", the rationale is basically the one Brett gave on python-dev (which was a restatement of the one that led to the change in python-dev): it's genuinely annoying as a Python developer to get deprecation warnings in your terminal for things like mypy, pylint, flake8, pip, pipenv, etc.

Why would mypy, flake8 or pip emit DeprecationWarnings?
The original problem was about end-user applications, not specialist
developer tools such as pip or mypy.  Specialist developer tools can
enable whatever warnings filter suits them, and that's what we're
promoting for test runners for instance.

But the problem is that, by silencing warnings in end-user applications
(where those warnings may indeed annoy users), in turn we defeat the
whole point of warnings since the developers of those applications
become ignorant of them.  That's the recurring theme of the whole
discussion thread, and your proposal ignores it.

(and I don't think chastising those application developers because they
don't have good enough test coverage will do much to alleviate the
problem; that's how a lot of software still gets written)

> The PEP will thus propose a middle-ground that leaves FutureWarning and PendingDeprecationWarning alone (so folks can still choose those semantics if they prefer them), but tweaks the semantics of DeprecationWarning such that common app distribution techniques (the console_scripts and gui_scripts entry_points, zipapp, executable packages) will still leave them off by default.

Did someone like Nathaniel confirm that the change you're proposing
would satisfy his use cases?  If not, I don't think you're achieving
anything useful here.