<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Dec 5, 2017 at 12:10 PM, Victor Stinner <span dir="ltr"><<a href="mailto:victor.stinner@gmail.com" target="_blank">victor.stinner@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">2017-12-05 19:24 GMT+01:00 Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>>:<br>
>> I disagree that *users* of an application is supposed to "handle"<br>
>> deprecation warnings: report them to the developer, or even try to fix<br>
>> them. IHMO these warnings (hidden by default) were introduced for<br>
>> developers of the application.<br>
><br>
> But the whole point of the PEP is that it only warns about deprecations in<br>
> code over which the user has control -- likely __main__ is their own code,<br>
> and they *can* handle it.<br>
<br>
</span>IMHO the core of the PEP 565 is to propose a compromise to separate<br>
"own code" and "external code" (cannot be modified).<br>
<br>
I'm unhappy with this suboptimal compromise: "only __main__ is my own<br>
code". Maybe we need something to declare the code that we own, to<br>
enable warnings on them. Just a simple helper on top of<br>
warnings.filterwarnings()? Or maybe I'm already in the "the better is<br>
the enemy of the good" greay area :-)<span class="HOEnZb"></span><br clear="all"></blockquote></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">This is a very good characterization of the dilemma. But IMO we don't have a better proxy for "my own code" (it's tempting to try and define it based on the current directory but this makes too many assumptions about development styles).<br></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>