On 28 November 2017 at 09:52, Guido van Rossum <guido@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/ 47ea35f0510dab2b01e18ff437f95c 6b1b75f2e6
Cheers,
Nick.