Python 3 adoption
Python 3 adoption
Posted Apr 18, 2015 6:39 UTC (Sat) by Cyberax (✭ supporter ✭, #52523)In reply to: Python 3 adoption by fandingo
Parent article: 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.
> The Python developers made a new point release, and spent a considerable amount of time discussing and warning about the change.
A 'point release' would be Python 2.8, they issued a minor update instead.
> 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.
There are now fixes for the SSL behavior. Other than that, gevent simply works. Why should it change every month?
> 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.
And that's the problem. Python developers shouldn't expect people to scramble to do substantial code rewrites for patchlevel releases.
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
To cut a long thread short
A 'point release' would be Python 2.8, they issued a minor update instead.