(prepep) Preventing future issues with warnings as errors

[mikeshardmind (Michael H)]

I don’t want to turn this into a rehash of fighting about pep 765, but for those unaware, the problems with it were recently summed up in the thread about it.

This summation is relevent to points 1 and 2, and I believe that if points one and two are adhered to as part of process, it would prevent a repeat.

@storchaka

There are some unique issues related to implementation of the PEP 765 warnings. Other warnings are emitted either in the lexer/tokenizer or in the code generator. But the PEP 765 warnings are generated in a separate step which is executed twice when use ast.parse() for getting an AST and then compile() to compile the AST. Compilation emits multiple warnings in the finally block · Issue #131927 · python/cpython · GitHub

The fix for this issue was not correct – it introduced other bugs (Syntax warnings can be swallowed in import · Issue #139640 · python/cpython · GitHub), and is incompatible with solutions for other issue (Better module info for SyntaxWarnings during AST parsing · Issue #135801 · python/cpython · GitHub). Both of them affect ability to discover and fix the original PEP 765 issue. So it should be reverted, but then we should apply an alternative solution for warning duplication.

While I somewhat agree with 3 and 4, I would really prefer if such new warnings were just left to linters in the future.

Something that was proposed in that thread that sort of slipped by in much of the frustration was the potential for a core developer endorsed lint configuration that was tailored for things that are known common footguns, and a way to easily ship this with the interpreter, but as a seperate tool the interpreter runs (Even if it runs it by default to help those who don’t know to know to turn it on), not as part of the interpreter core itself.