OK, thanks.
The more I think about this, the more confused I get, though. The first time code with this problem gets imported in a fresh environment, the user will see a warning, but never again after that. But if they use -Werror
, they’ll see the error every time, unless they didn’t use -Werror
the very first time, when they’ll never see the error. Or something like that… And all of this applies both to the library developer and to any users of the library?
And what’s worse, the only way of fixing it is for the library developer to change the code (and release a new version). Because as far as I can see, the runtime warning filter doesn’t work for syntax warnings:
❯ py -c "import warnings; warnings.simplefilter('ignore', SyntaxWarning); assert (1,2)"
<string>:1: SyntaxWarning: assertion is always true, perhaps remove parentheses?
While I appreciate that this problem may be very rare, a syntax warning seems like it will cause at least as many problems as we’ve had with other forms of deprecation warnings. IMO, if we think this needs to be prohibited, we should stand by our decision, and simply make it an error. If there’s too much risk of disruption from doing that, I think there’s also too much risk of disruption using a syntax warning.