Sorry, I still don’t understand how any of this is a problem. 1. If you’re an application developer, google “python disable DeprecationWarning” and paste the code you found, so your users don’t see the warnings. 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. 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. Best, Philipp Nick Coghlan <ncoghlan at gmail.com> schrieb am Di., 7. Nov. 2017 um 13:25 Uhr: > On 7 November 2017 at 19:30, Paul Moore <p.f.moore at gmail.com> wrote: > > On 7 November 2017 at 04:09, Nick Coghlan <ncoghlan at gmail.com> 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. > > We'd then offer some straightforward interfaces for people to say > "Please also report legacy calls from 'module' as warnings". > > You'd still get less-than-helpful warnings if you were running a > single file script that someone *else* wrote (rather than one you > wrote yourself), but that's an inherent flaw in that distribution > model: as soon as you ask people to supply their own Python runtime, > you're putting them in the position of acting as an application > integrator (finding a combination of Python language runtime and your > script that actually work together), rather than as a regular software > user. > > Cheers, > Nick. > > -- > Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/flying-sheep%40web.de > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20171107/1393b3b5/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4