Hacker News Reader

Comment by maaku | Hacker News Reader

It's not so simple. As mentioned in the last paragraph, for example, Ubuntu LTS will release with Python 3.2. Backporting this feature to 3.2 will make it available to (updated and patched) Ubuntu LTS installs. NOT backporting this PEP could result in further delays in Python 3 adoption as people wait for Ubuntu 14.04 LTS.

View on HN

A good point. I do wonder what proportion of Ubuntu users take advantage of the LTS releases rather than, say, just outright using Debian. I also intuitively want to say that anyone deciding to go with a LTS release would, if given the choice between a 2.7 library and a 3.2 library, choose the more "mature" option anyway.

I agree that it would have been smart to backport such a seemingly small and unobtrusive change to 3.2 (and who knows, maybe they still will).

Actually, no, after contemplation I realize that it would be much worse to split the compatibility of 3.2 and force library authors to qualify their compatibility targets by the minor version. After all, if the hypothetical 3.2.new didn't require any porting effort to support 3.3-style unicode literals, then library authors would have even less incentive to port their libraries to 3.2.old for all the people who can't upgrade, or won't upgrade, or who don't realize that their version doesn't feature a critical language addition.

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?

  > 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).

Modern stack is just not compatible with Ubuntu LTS. You can either pull stuffs from ppa, build them from source, roll your own packages, or, heaven forbid, choose a better distro.

Reply on news.ycombinator.com