Python 3 adoption
Python 3 adoption
Posted Apr 16, 2015 22:56 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)In reply to: Python 3 adoption by fandingo
Parent article: Python 3 adoption
This diff alone isn't.
> I am also still curious about the timeline when this blew up because it doesn't make sense. I don't see Debian or Ubuntu backporting these SSL changes. Outside of Debian Sid and Ubuntu 14.10, I'm struggling to even find an apt-based distro that actually has 2.7.9. Even Sid and 14.10 only got 2.7.9 1 month ago.
The Ubuntu 14.04 backport was committed sometime in December. You can see the offending code in the Ubuntu patch: http://archive.ubuntu.com/ubuntu/pool/main/p/python2.7/py... - grep for "_sslwrap".
Please note, that it's NOT Python 2.7.9, it's a backport to Python 2.7.8.
We started seeing it in the wild right after the New Year. I can try to get precise details from their version control repo.
> Sure that's possible. Which apt-based distro are you using that actually does this? Ubuntu and Debian only package one Python 2 version at a time, so you're talking about custom packaging.
Ubuntu did this during 2.6 -> 2.7 migration. You could install both versions alongside and either use an explicit '/usr/bin/python26' or use DPKG alternatives mechanism to select an interpreter.
And then there's CentOS 6 which is still packaged with Python 2.6 by default.
Incidentally, I don't see hordes torch-wielding of CentOS users demanding SSL fixes to be backported into Python 2.6
> Plus, your users are going to be using whatever the default is, and I can't see any situation where a hypothetical 2.8 doesn't become the default immediately in the next distro release.
That's fine. A transition period of 2-3 years (one release cycle) would have given everyone time to adapt or at least to explicitly set the Python version in scripts.
> Just the hypothetical ones that do things exactly like you want to avoid.
The problem was very real - people downloading default Ubuntu machine images on Amazon EC2 suddenly stopped being able to use our software.
Posted Apr 18, 2015 1:39 UTC (Sat)
by fandingo (guest, #67019)
[Link] (3 responses)
In that light, I can definitely understand why you'd be angry about breaking changes pulled into an earlier version within a distro version. Yet, I don't see what it has to do with the Python developers. The Python developers made a new point release, and spent a considerable amount of time discussing and warning about the change.
> That's fine. A transition period of 2-3 years (one release cycle) would have given everyone time to adapt or at least to explicitly set the Python version in scripts.
Is there any indication that the state of Gevent is actually going to change? There have been a couple of pull requests before the actual release of 2.7.9 to fix this behavior, and the author(s) haven't done anything with them. It seems like the only hope would be that Gevent is forked, and people start getting the fork through their distro or pypi.
All of that being said, the fix in Gevent was simple, and if that library was maintained, the library would've been updated 3 months before 2.7.9 was released, which was when the first patch and merge request were posted.
Posted Apr 18, 2015 6:39 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
> The Python developers made a new point release, and spent a considerable amount of time discussing and warning about the change.
> Is there any indication that the state of Gevent is actually going to change? There have been a couple of pull requests before the actual release of 2.7.9 to fix this behavior, and the author(s) haven't done anything with them.
> All of that being said, the fix in Gevent was simple, and if that library was maintained, the library would've been updated 3 months before 2.7.9 was released, which was when the first patch and merge request were posted.
Posted Apr 18, 2015 7:28 UTC (Sat)
by fandingo (guest, #67019)
[Link]
If by "safe" you mean without compatibility issues, then you're terribly, terribly wrong. You obviously didn't read the release notes or PEP 466, which are linked in the notes. I'm in disbelief that you could possibly make this comment after all that we've discussed.
> The same thing happened with SuSE and Amazon Linux.
SUSE is on Python 2.6, so no, it didn't. I still don't understand why more entities doing the wrong thing absolves them of fault. The ssl changes were 2.7.9; what possible situation exists for taking all of the changes and putting them in something called the previous version. That's madness.
> I think only RedHat/CentOS refrained from doing it.
And Fedora.
You're really not going to budge an inch that those distros messed up by putting this serious compatibility break that you bemoan in a package that they call 2.7.8 are you? Wow, that really makes it difficult to take you seriously.
> There are now fixes for the SSL behavior.
They've been there since September 21, 3 months before the release of 2.7.9. But there weren't any maintainers to merge the simple change, so no update was available. That's the part that you seem so unwilling to admit: The necessary packages were simple, and identified long before users were impacted, but because there isn't any active development of Gevent, the work never got published.
> Other than that, gevent simply works. Why should it change every month?
Not with the current 2.7 release, so yeah, it does need to change. Considering that there's 46 open merge requests for a litany of issues, I'd say that users would like to see quite a bit of change. I don't see why you're so happy and content with using unmaintained code. Perhaps it will take some remote execution vulnerability to change your mind.
> And that's the problem. Python developers shouldn't expect people to scramble to do substantial code rewrites for patchlevel releases.
In what world is a half-dozen lines of code 3 months in advance scrambling? This is such complete and utter nonsense.
Posted Apr 19, 2015 21:12 UTC (Sun)
by pboddie (guest, #50784)
[Link]
Most people won't read this far into this thread, but that's the real issue here: there's a policy decision not to release another minor version of Python 2.x, so that not only will the core developers not support a Python 2.8 release themselves, they will also deny others the opportunity to make such a version with that label; this is why Stackless Python was renamed to just Stackless. Personally, I find this aversion to even a single subsequent minor version (2.8 in this case), in a series that isn't favoured by its principal developers, to be counterproductive. Such a version is an ideal place to put all the backwards-incompatible fixes that "finish the job", instead of pretending that some other "final" minor version (2.7 in this case) wasn't broken all along. It also won't confuse distribution packagers who risk breaking things because they didn't follow or can't second-guess every last policy decision of the core developers, see a "patch release" and dish it out believing that the usual conservatism has been upheld. In short, changing the rules and making late updates to 2.7.x into something they shouldn't have been is what has caused this problem. Conceding that 2.8 should have existed for such purposes, perhaps explicitly indicating a change to the rules for that version, would have been the correct decision.
Python 3 adoption
Python 3 adoption
The same thing happened with SuSE and Amazon Linux. They all have backported a patch that Python developers insisted was safe and essential. I think only RedHat/CentOS refrained from doing it.
A 'point release' would be Python 2.8, they issued a minor update instead.
There are now fixes for the SSL behavior. Other than that, gevent simply works. Why should it change every month?
And that's the problem. Python developers shouldn't expect people to scramble to do substantial code rewrites for patchlevel releases.
Python 3 adoption
To cut a long thread short
A 'point release' would be Python 2.8, they issued a minor update instead.