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
On 28 November 2017 at 09:52, Guido van Rossum
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@gmail.com | Brisbane, Australia
-- --Guido van Rossum (python.org/~guido)