[Python-Dev] Proposal: go back to enabling DeprecationWarning by default

[Philipp A.]

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>