The Python 3.10 integer-narrowing change continues to catch people unawares. Here are four GitHub issues/PRs related to code that started crashing when run under Python 3.10. The interesting thing is that all four of these are from the past two months:
The thing is that these issues could have been caught much earlier. All of this code was previously being run, presumably regularly and presumably by multiple people, under Python versions 3.9, 3.8, etc… Narrowing conversions of floats to integers were already deprecated in those versions, and could have produced visible DeprecationWarning messages… were those messages not disabled by default!
I sort of get the arguments for disabling them. DeprecationWarnings, it can be argued, aren’t meant for endusers — they’re meant for the developers of the code in question, so why distract/bother the enduser with them? There’s nothing they can do about those warnings, right?
Both of those assertions are incorrect, though.
-
DeprecationWarnings absolutely are of interest to the enduser, because ultimately they’re the ones running (and depending on) the code that’s making use of deprecated features (no matter how indirectly). And ultimately, the software is going to fail for them if those deprecations are not addressed. I’d argue endusers are far more invested in code stability than the code’s developers are, when it comes right down to it.
-
There is absolutely something that endusers can do about DeprecationWarnings: They can file bugs, they can report them to the developers, they can agitate for them to be addressed so that, when those deprecations eventually become errors, that doesn’t translate into a sudden failure of their critical application.
Also, for better or for worse the reality is that endusers will always represent a more heterogeneous test environment than any the developer can provide for their own testing. We rely on endusers to report bugs running our code on platforms, with dependency versions, and in situations that our testing never evaluated.
Many independent developers with limited resources at their disposal don’t employ a comprehensive, multi-version, multi-platform testing infrastructure. And in those cases, testing is often limited to the oldest supported versions of their dependencies in order to limit use of newer features that prevent their code from being backwards-compatible with those older versions. Which means that it’s often the endusers, not the developers, who are the first ones to run some code under the most recent Python releases.
When they do, they should be made aware of any deprecated functionality being relied upon in that code, as a first step towards getting that issue addressed.
As an enduser, try running basically any software written in Python with PYTHONWARNINGS=always set in the process environment. Whenever I do that, I’m always amazed at the flood of messages, primarily DeprecationWarnings, that spews from the terminal.
The reason there are so many uses of deprecated functionality is that nobody is paying attention to them, and therefore nobody is addressing them! And that translates into painful surprises down the road, when things that should have been fixed ages ago suddenly blow up in our collective faces.