[Python-Dev] PEP 565: show DeprecationWarning in __main__ (round 2)

[Guido van Rossum]

This is awesome. If there isn't more feedback in the next few days expect
an approval early next week. (Ping me if you don't hear from me, I'm
juggling way too many small tasks so I'm likely to forget some.)

On Tue, Nov 28, 2017 at 3:00 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 28 November 2017 at 09:52, Guido van Rossum <guido at python.org> wrote:
> > I am basically in agreement with this now. Some remarks:
>
> I've pushed an update which should address most of these, as well as
> Serhiy's comment about the existing FutureWarning use case:
> https://github.com/python/peps/commit/aaa64f53d0434724384b056a3c195d
> 63a5cc3761
>
> > - I would recommend adding a note to the abstract about the
> recommendation
> > for test runners to also enable these warnings by default.
>
> Done.
>
> > - Would be nice to know whether IPython/Jupyter is happy with this.
>
> They implemented a solution along these lines some time ago, so I've
> added a new subsection with advice for folks writing interactive
> shells, and quoted their warnings.filterwarnings call as an example of
> how to do it (with a link to the relevant line in their repo).
>
> > - The sentence "As a result, API deprecation warnings encountered by
> > development tools written in Python should continue to be hidden by
> default
> > for users of those tools" is missing a final period; I also think that
> the
> > argument here is stronger if "development" is left out. (Maybe
> development
> > tools could be called out in a "for example" clause.)
>
> I ended up rewording that paragraph completely (partly prompted by
> your comment about the impact on single file scripts).
>
> > - I can't quite put my finger on it, but reading the three bullets of
> > distinct categories of warnings something seems slightly off, perhaps
> due to
> > independent editing of various phrases. Perhaps the three bullets could
> be
> > rewritten for better correspondence between the various properties and
> > audiences? And what should test runners do for each?
>
> I think I was trying to do too much in that list of categories, so I
> moved everything related to test runners out to a new dedicated
> section.
>
> That means the list of categories can focus solely on the actual
> defaults, while the new test runner section describes how we expect
> test runners to override that.
>
> I also noticed something that seemed worth mentioning in relation to
> BytesWarning, which is that "-Wd" works as well as it does because the
> interpreter doesn't even *try* to emit those warnings if you don't
> pass "-b" or "-bb" on the command line. The warnings filter only
> handles the "Should it be a warning or an exception?" part.
>
> > - Also, is SyntaxWarning worth adding to the list?
>
> I *haven't* added this, since our only current syntax warning that I
> can see is the one for "assert ('always', 'true')", and we've been
> more inclined to go down the DeprecationWarning->SyntaxError path in
> recent years than we have to settle for a persistent syntax warning.
>
> > - The thing about FutureWarning being present since 2.3 feels odd -- if
> your
> > library cares about supporting 2.7 and higher, should it use
> FutureWarning
> > or DeprecationWarning?
>
> I reworded this paragraph to make it more prescriptive and say "Use
> DeprecationWarning on 3.7+, use FutureWarning on earlier versions if
> you don't think the way they handle DeprecationWarning is noisy
> enough")
>
> > - "re-enabling deprecation warnings by default in __main__ doesn't help
> in
> >   handling cases where software has been factored out into support
> modules,
> > but
> >   those modules still have little or no automated test coverage."
> >   This and all bullets in the same list should have an initial capital
> > letter and trailing period.
>
> Fixed.
>
> > This sentence in particular also reads odd: the
> > "but" seems to apply to everything that comes before, but actually is
> meant
> > to apply only to "cases where ...". Maybe rephrasing this can help the
> > sentence flow better.
>
> I missed this comment initially. Follow-up commit to reword that
> sentence: https://github.com/python/peps/commit/
> 47ea35f0510dab2b01e18ff437f95c6b1b75f2e6
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171128/f57d6609/attachment.html>