(prepep) Preventing future issues with warnings as errors

[Liz (Elizabeth King)]

@corona10

It has come to our attention that our earlier statement was misinterpreted by some. Our wording was not clear enough, and we would like to clarify our intent.

The Steering Council continues to fully support both the intent and direction of PEP 765. The PEP promotes clearer and more predictable control flow, which aligns with Python’s design philosophy and long-term goals.

When we said it was “too late” to revert, that was not meant to imply that we regretted the decision. We meant that even if a PEP were made to revert the feature for 3.14, we were in the release candidate stage, and reverting the change for the 3.14 release would have created more disruption and uncertainty than it would have solved. We acknowledge that this SyntaxWarning has an impact on some users, we were aware of that when deciding to accept the PEP. We value the feedback received and welcome new ideas and perspectives. Anyone who believes that PEP 765 or its implementation should be reconsidered or would like to improve the state of warnings in Python in general is encouraged to work towards a new PEP targeted for a future Python, with clear motivation and supporting evidence, rather than reopening discussion on an accepted one.

To summarize:

• PEP 765 remains accepted and will not be reverted in 3.14.
• Future discussion on this topic should proceed through a new PEP if there is strong motivation to do so.

Warm regards,
Donghee
on behalf of the Python Steering Council

(Taken from a now locked thread, into the one where I intend to do as suggested and try and improve the case for use of warnings.)

Given the tone of the response was in reaffirming 765’s acceptance, and not at all addressing that the issues that came up did not require reversing 765 to have been addressed, I want to reiterate that while I think it isn’t the place of the interpreter to act as a linter, I was fine with it up until it reached users specifically who weren’t supposed to reach it by the pep’s design ^[1] and that it wasn’t filterable using existing filtering mechanisms.

As has been said already, other syntax warnings weren’t filterable before. However, all prior existing SyntaxWarnings are unambiguously erroneous. The most favorable example is the below:

>>> a = 1; print(1 is 1)
<stdin>:1: SyntaxWarning: "is" with 'int' literal. Did you mean "=="?
True

In other words, the filter may have already been broken for syntax warnings, but prior syntax warnings were so conservative in what they warned for, that this wasn’t observed or fixed, because it was pointing out broken code and filtering it made no sense to do.

Given this context, and the tone of the response, I have to ask if the steering council was only aware of the theoretical disruption that comes with all new warnings, or was it intentionally pushed forward with the steering council aware that it was also not working as the pep advertised (the “clever” mechanism of using the bytecode cache didn’t have the intended effect of only the library author seeing it) and that it was also in the context of the warning not being filterable?

These issues were brought up in the discourse thread relatively early on, and there was a PR available to fix the filtering issue that did not make it into 3.14.

I’d like to be able to trust warnings as errors going forward, so I’d like to understand what parts of the process led here that I no longer feel I can so that I can propose something that actually addresses what failed here.

---

1. The pep specifically attempted to only reach library authors by use of the bytecode cache. It was shown early on in the release cycle that users that were testing ran into this with library code in CI. ↩︎