4 ms·
in my experience, people (and distros) will update minor versions in mid-life patches/updates. so backporting gets this fix to "legacy" installs, where a new p
by andrewcooke 15y ago
in my experience, people (and distros) will update minor versions in mid-life patches/updates. so backporting gets this fix to "legacy" installs, where a new python version is not acceptable (i have clients with python 2.5 - 5 years from now the same kinds of people will be stuck on 3.1).
and i'm not sure why comparing three digits rather than two is so much more difficult. can you expand on your logic there?
- kibwen 15y ago> and i'm not sure why comparing three digits rather than two is so much more difficult. can you expand on your logic there? Really only because it defies what people are used to. I really shouldn't have referred to that third number as the "minor version number", perhaps "the bugfix version number" would have been more appropriate, as that's what people (broadly speaking) expect it to stand for. I acknowledge that there are arguments to be made for both viewpoints. However, I don't think that the risk of slightly delaying adoption of Python 3k due to concerns of a "compatibility hole" with Python 3.2 are worth introducing even more version chaos into the Python ecosystem. (You could just as easily argue that this move would prevent version chaos by eradicating the compatibility hole, but there will always those people who will forever be stuck on 3.2.old, for whatever reason.) I could be wrong! But regardless of what I think, the fact that the preceding argument can even be raised seems to indicate that it would be politically untenable for the Python devteam to suggest such a course of action. As far as they're concerned, Py3k adoption is progressing at a reasonable pace (though clearly not as smoothly as they'd hoped).