On Tue, Aug 6, 2019 at 3:44 PM Brett Cannon <br...@python.org> wrote: > I think this is a good example of how the community is not running tests with > warnings on and making sure that their code is warnings-free. This warning > has existed for at least one full release and fixing it doesn't require some > crazy work-around for backwards compatibility, and so this tells me people > are simply either ignoring the warnings or they are not aware of them. > > If it's the case that people are choosing to ignore warnings then that's on > them and there's not much we can do there. > > But my suspicion is it's the latter case of people simply not thinking about > running with warnings on and making sure to check for them. For instance, are > people running their CI with warnings turned on? How about making sure to > check the output of their CI to make sure there are no warnings? Or even > better, how many people are running CI with warnings turned into exceptions? > My guess is all of this is rather low because people are probably just doing > `pytest` without thinking of turning on warnings as exceptions to trigger a > CI failure and are only looking for CI passing versus checking its output.
There's an important point here that I think has been missed. These days deprecation warnings are much more visible in general, because all the major test systems enable them by default. BUT, this SPECIFIC warning almost completely circumvented all those systems, so almost no-one saw it. For example, all my projects run tests with deprecation warnings enabled and warnings turned into errors, but I never saw any of these warnings. What happens is: the warning is issued when the .py file is byte-compiled; but at this point, deprecation warnings probably aren't visible. Later on, when pytest imports the file, it has warnings enabled... but now the warning isn't issued. Quoting Aaron Meurer from the bpo thread: > As an anecdote, for SymPy's CI, we went through five (if I am counting > correctly) iterations of trying to test this. Each of the first four were > subtly incorrect, until we finally managed to find the correct one (for > reference, 'python -We:invalid -m compileall -f -q module/'). So most > library authors who will attempt to add tests against this will get it wrong. Since folks don't seem to be reading that thread, I'll re-post my comment from it as well: > I think we haven't *actually* done a proper DeprecationWarning period for > this. We tried, but because of the issue with byte-compiling, the warnings > were unconditionally suppressed for most users -- even the users who are > diligent enough to enable warnings and look at warnings in their test suites. > I can see a good argument for making the change, but if we're going to do it > then it's obviously the kind of change that requires a proper deprecation > period, and that hasn't happened. > Maybe .pyc files need to be extended to store a list of syntax-related > DeprecationWarnings and SyntaxWarnings, that are re-issued every time the > .pyc is loaded? Then we'd at least have the technical capability to deprecate > this properly. -n -- Nathaniel J. Smith -- https://vorpus.org _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/E7QCC74OBYEY3PVLNQG2ZAVRO653LD5K/
