3 ms·

It says a lot about the way this tooling is being used that five years of deprecation warnings still isn't enough to get people to port over their software. Pe

It says a lot about the way this tooling is being used that five years of deprecation warnings still isn't enough to get people to port over their software. Perhaps this should've been implemented as a gradual failure with a temporary workaround ("as of X, this feature will break unless you specify the MY_CODE_WILL_BREAK_IN_OCTOBER=1 environment variable" rather than just breaking after an update), though I doubt that would've changed much.

enriquto 2y ago
Or maybe, you know, just don't knowingly break other people's working code.
- skeledrew 2y ago
  And so never improve the language and ecosystem.
  - enriquto 2y ago
    Linux and Windows keep supporting even blatant bugs for decades, in order not to break old working code that relies on these bugs. The ecosystem keeps evolving healthily under that constraint. Breaking working code for an essentially stylistic change of API is not even malice. It's plain stupidity.
    - skeledrew 2y ago
      An OS isn't touched anywhere near as much by a diverse user base as a language and ecosystem like Python is. It can be more or less guaranteed that everyone building things directly on top of an OS already has a very good idea of what they're doing, and are likely aware of any strange quirks or workarounds they may need to consider. And if they don't, they know how and where to seek help. This is definitely not the case with most Python users, and as such, when bugs and bad practices can be remedied or mitigated they should be, so the many who just want to get their pipeline or automation scripts going can do so without polluting 101 channels with low quality questions and time-wasting problems.
eesmith 2y ago
The warnings were only generated when doing "python setup.py test". No warnings were emitted with "from setuptools.command import test", which is what people did to modify how the "test" command works. If someone used to use "setup.py test" with a modified command, then switched to another way to run the tests, but forgot to remove the old code, then they would never get the warnings (because it required running "test"), yet the code broke (because the import failed).

enriquto 2y ago

Or maybe, you know, just don't knowingly break other people's working code.

skeledrew 2y ago
And so never improve the language and ecosystem.
- enriquto 2y ago
  Linux and Windows keep supporting even blatant bugs for decades, in order not to break old working code that relies on these bugs. The ecosystem keeps evolving healthily under that constraint. Breaking working code for an essentially stylistic change of API is not even malice. It's plain stupidity.
  - skeledrew 2y ago
    An OS isn't touched anywhere near as much by a diverse user base as a language and ecosystem like Python is. It can be more or less guaranteed that everyone building things directly on top of an OS already has a very good idea of what they're doing, and are likely aware of any strange quirks or workarounds they may need to consider. And if they don't, they know how and where to seek help. This is definitely not the case with most Python users, and as such, when bugs and bad practices can be remedied or mitigated they should be, so the many who just want to get their pipeline or automation scripts going can do so without polluting 101 channels with low quality questions and time-wasting problems.

eesmith 2y ago

The warnings were only generated when doing "python setup.py test". No warnings were emitted with "from setuptools.command import test", which is what people did to modify how the "test" command works. If someone used to use "setup.py test" with a modified command, then switched to another way to run the tests, but forgot to remove the old code, then they would never get the warnings (because it required running "test"), yet the code broke (because the import failed).