<div dir="ltr"><div><div><font size="2">Sorry, I still don’t understand how any of this is a problem.</font></div></div><div><ol><li><font size="2">If you’re an application developer, google “python disable DeprecationWarning” and paste the code you found, so your users don’t see the warnings.</font></li><li><font size="2">If you’re a library developer, and a library you depend on raises DeprecationWarnings without it being your fault, file an issue/bug there.</font></li></ol><div><font size="2">For super-increased convenience in case 2., we could also add a convenience API that blocks deprecation warnings raised from certain module or its submodules.</font></div></div><div><font size="2">Best, Philipp</font></div></div><br><div class="gmail_quote"><div dir="ltr">Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> schrieb am Di., 7. Nov. 2017 um 13:25 Uhr:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 7 November 2017 at 19:30, Paul Moore <<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>> wrote:<br>
> On 7 November 2017 at 04:09, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>> wrote:<br>
>> Given the status quo, how do educators learn that the examples they're<br>
>> teaching to their students are using deprecated APIs?<br>
><br>
> By reading the documentation on what they are teaching, and by testing<br>
> their examples with new versions with deprecation warnings turned on?<br>
> Better than having warnings appear the first time they run a course<br>
> with a new version of Python, surely?<br>
><br>
> I understand the "but no-one actually does this" argument. And I<br>
> understand that breakage as a result is worse than a few warnings. But<br>
> enabling deprecation warnings by default feels to me like favouring<br>
> the developer over the end user. I remember before the current<br>
> behaviour was enabled and it was *immensely* frustrating to try to use<br>
> 3rd party code and get a load of warnings. The only options were:<br>
><br>
> 1. Report the bug - usually not much help, as I want to run the<br>
> program *now*, not when a new release is made.<br>
> 2. Fix the code (and ideally submit a PR upstream) - I want to *use*<br>
> the program, not debug it.<br>
> 3. Find the right setting/environment variable, and tweak how I call<br>
> the program to apply it - which doesn't fix the root cause, it's just<br>
> a workaround.<br>
<br>
Yes, this is why I've come around to the view that we need to come up<br>
with a viable definition of "third party code" and leave deprecation<br>
warnings triggered by that code disabled by default.<br>
<br>
My suggestion for that definition is to have the *default* meaning of<br>
"third party code" be "everything that isn't __main__".<br>
<br>
That way, if you get a deprecation warning at the REPL, it's<br>
necessarily because of something *you* did, not because of something a<br>
library you called did. Ditto for single file scripts.<br>
<br>
We'd then offer some straightforward interfaces for people to say<br>
"Please also report legacy calls from 'module' as warnings".<br>
<br>
You'd still get less-than-helpful warnings if you were running a<br>
single file script that someone *else* wrote (rather than one you<br>
wrote yourself), but that's an inherent flaw in that distribution<br>
model: as soon as you ask people to supply their own Python runtime,<br>
you're putting them in the position of acting as an application<br>
integrator (finding a combination of Python language runtime and your<br>
script that actually work together), rather than as a regular software<br>
user.<br>
<br>
Cheers,<br>
Nick.<br>
<br>
--<br>
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org" target="_blank">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/flying-sheep%40web.de" rel="noreferrer" target="_blank">https://mail.python.org/mailman/options/python-dev/flying-sheep%40web.de</a><br>
</blockquote></div>