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

Nick Coghlan ncoghlan at gmail.com
Tue Nov 28 06:00:47 EST 2017

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:

> - I would recommend adding a note to the abstract about the recommendation
> for test runners to also enable these warnings by default.


> - 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

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

> - "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.


> 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


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list