3 ms·

I would counterargue that it adds stress for no good reason, and it leads to exactly the opposite result. If I want to collaborate with someone we now need to

I would counterargue that it adds stress for no good reason, and it leads to exactly the opposite result. If I want to collaborate with someone we now need to agree on multiple versions of multiple libraries - if my code needs at least version 3.6 because I use f-strings but their code needs 3.5 because a library will otherwise break, we now have a stress point that we don't need. Even worse, I might have to collaborate with someone who is not a programmer (very common in data science) and now I need to spend an hour guiding them through the update process plus time in the future to fix whatever the upgrade broke in the background. For a language that made "easy to use" a selling point, that is less than ideal. (Side note: it also makes Python the only language for which I regularly need to check the date in Stack Overflow answers, as those get outdated faster than, say, Bash scripts). How does that get solved in practice? In my experience, by pinning everything to 3.5 or 3.6 and never updating.

lmm 6y ago
> If I want to collaborate with someone we now need to agree on multiple versions of multiple libraries - if my code needs at least version 3.6 because I use f-strings but your code needs 3.5 because a library will otherwise break, we now have a stress point that we don't need. The longer the interval between releases the more likely that kind of library incompatibility is, and the more likely an upgrade becomes too much trouble to be worthwhile. If you have to upgrade one library to be able to upgrade your Python version, you can probably manage to test that. If you have to upgrade four libraries you're more likely to give up and pin to the version you're currently on.
- Macha 6y ago
  I think the kind of breaking changes people want to actually use are less frequent than incompatible changes in general. E.g. this zoneinfo library is something where the reaction is "great, I can drop a dependency in 3-4 years" while fstrings are a lot more compelling to some people as it fixes a papercut they have with long format calls. I don't see many libraries raising their minimum python version for zoneinfo as a result, while libraries did for fstrings.
abiogenesis 6y ago
Python's release policy is pretty sane as they try to overlap maintenance periods. Python 3.8 will still be supported for another 3+ years after 3.9 is released.
- rightbyte 6y ago
  Three years is like tomorrow for breaking changes. I have come to apriciate the slow moving tools more and more the older I get.
  - joshuamorton 6y ago
    There aren't any breaking changes in 3.9.
HelloNurse 6y ago
Withstanding stress is a sufficient good reason. When you need to deploy a security fix with a deadline of a week ago, it has to go smoothly; and it's going to go smoothly because everyone involved knows how to update everything reliably and efficiently. > now I need to spend an hour guiding them through the update process The update process should consist of deleting site-packages and Python binaries, installing Python, and running a simple script consisting mainly of "pip install x y z" steps. Or nowadays replacing a whole Docker coffin with an updated one. Can you elaborate on the required "guiding"?

lmm 6y ago

> If I want to collaborate with someone we now need to agree on multiple versions of multiple libraries - if my code needs at least version 3.6 because I use f-strings but your code needs 3.5 because a library will otherwise break, we now have a stress point that we don't need. The longer the interval between releases the more likely that kind of library incompatibility is, and the more likely an upgrade becomes too much trouble to be worthwhile. If you have to upgrade one library to be able to upgrade your Python version, you can probably manage to test that. If you have to upgrade four libraries you're more likely to give up and pin to the version you're currently on.

Macha 6y ago
I think the kind of breaking changes people want to actually use are less frequent than incompatible changes in general. E.g. this zoneinfo library is something where the reaction is "great, I can drop a dependency in 3-4 years" while fstrings are a lot more compelling to some people as it fixes a papercut they have with long format calls. I don't see many libraries raising their minimum python version for zoneinfo as a result, while libraries did for fstrings.

abiogenesis 6y ago

Python's release policy is pretty sane as they try to overlap maintenance periods. Python 3.8 will still be supported for another 3+ years after 3.9 is released.

rightbyte 6y ago
Three years is like tomorrow for breaking changes. I have come to apriciate the slow moving tools more and more the older I get.
- joshuamorton 6y ago
  There aren't any breaking changes in 3.9.

HelloNurse 6y ago

Withstanding stress is a sufficient good reason. When you need to deploy a security fix with a deadline of a week ago, it has to go smoothly; and it's going to go smoothly because everyone involved knows how to update everything reliably and efficiently. > now I need to spend an hour guiding them through the update process The update process should consist of deleting site-packages and Python binaries, installing Python, and running a simple script consisting mainly of "pip install x y z" steps. Or nowadays replacing a whole Docker coffin with an updated one. Can you elaborate on the required "guiding"?