On Nov 7, 2017 06:24, "Nick Coghlan"
On 7 November 2017 at 04:09, Nick Coghlan
wrote: Given the status quo, how do educators learn that the examples they're teaching to their students are using deprecated APIs?
By reading the documentation on what they are teaching, and by testing their examples with new versions with deprecation warnings turned on? Better than having warnings appear the first time they run a course with a new version of Python, surely?
I understand the "but no-one actually does this" argument. And I understand that breakage as a result is worse than a few warnings. But enabling deprecation warnings by default feels to me like favouring the developer over the end user. I remember before the current behaviour was enabled and it was *immensely* frustrating to try to use 3rd party code and get a load of warnings. The only options were:
1. Report the bug - usually not much help, as I want to run the program *now*, not when a new release is made. 2. Fix the code (and ideally submit a PR upstream) - I want to *use* the program, not debug it. 3. Find the right setting/environment variable, and tweak how I call the program to apply it - which doesn't fix the root cause, it's just a workaround.
Yes, this is why I've come around to the view that we need to come up with a viable definition of "third party code" and leave deprecation warnings triggered by that code disabled by default. My suggestion for that definition is to have the *default* meaning of "third party code" be "everything that isn't __main__". That way, if you get a deprecation warning at the REPL, it's necessarily because of something *you* did, not because of something a library you called did. Ditto for single file scripts. IPython actually made this change a few years ago; since 2015 I think it has shown DeprecationWarnings by default if they're triggered by __main__. It's helpful but I haven't noticed it eliminating this problem. One limitation in particular is that it requires that the warnings are correctly attributed to the code that triggered them, which means that whoever is issuing the warning has to set the stacklevel= correctly, and most people don't. (The default of stacklevel=1 is always wrong for DeprecationWarning.) Also, IIRC it's actually impossible to set the stacklevel= correctly when you're deprecating a whole module and issue the warning at import time, because you need to know how many stack frames the import system uses. -n