There are a lot of comments here from people who aren't on the python-dev list and don't really understand what this diff actually means.<p>The core developers are not required to maintain 2.7 post-2015, and most of them won't be involved in it. That part hasn't changed.<p>What is happening is that Red Hat is preparing to cut a RHEL 7 release, which AFAIK depending on how much you pay them they support for 13 years. So they will need to figure out how to support 2.7 themselves at least through 2027.<p>Here is where I am reading between the lines. RH are well within their right to fork Python and keep their maintenance patches to themselves and their customers (Python's not copyleft). But, they are nice guys and so maybe they are willing to upstream their changes at least for awhile if there is still a Python project willing to accept them. Again, this is my speculation based on the ML discussion, not what RH has actually said they will do.<p>An analogy can be made to Rails LTS, a commercial fork of Rails 2.x that patio11 was involved in [0]. Inevitably somebody is going to step in to support 2.7, and so let's see what we can do to avoid a situation where the only way to keep running 2.7 is to subscribe to RHEL.<p>Meanwhile, there are some large companies that use 2.7 extensively on Windows (e.g. Enthought, Anaconda) and the thinking goes that somebody can probably be found to produce a Windows installer once in awhile, assuming that Python.org will still host a download.<p>So really what is happening here is not very exciting. The core committers aren't doing anything different than leaving the project as originally planned. What is happening is that they will leave the lights on in the source control repository and on the FTP server, so as to capture the free labor from people at large companies who have an interest in continuing to support 2.7.<p>The alternative is that RH and other vendors create proprietary and expensive forks of Python 2.7. That may end up happening anyway, but it will take longer for your employer to notice you should stop contributing your patches back if binaries still appear on python.org and you don't have to ask IT to set up SCM and a bug tracker, etc.<p>[0] <a href="http://www.kalzumeus.com/2013/06/17/if-your-business-uses-rails-2-3-you-need-to-move-to-a-supported-option-asap/" rel="nofollow">http://www.kalzumeus.com/2013/06/17/if-your-business-uses-ra...</a>
This is really disappointing to see - I fear that it will slow adoption of Python 3 even further, when it was just reaching a tipping point[0].<p>When I first learned Python, I learned Python 3 first because it was newer, and I figured everyone would be using it soon enough. Little did I know that Python 2 would continue to be supported for over ten years after that!<p>Some people make a big deal about figuring out "which" Python to learn - that's not really much of an issue, because Python 3 isn't so different from Python 2 that it's hard to pick up the other very quickly (especially given how much has been backported to 2.7). But it's unfortunate to see people continuing to write new code in Python 2.<p>[0] <a href="http://python3wos.appspot.com/" rel="nofollow">http://python3wos.appspot.com/</a>
How I'm not surprised.<p>Python 3 didn't offer anything that would have been so useful and desirable that people would've jumped on it the moment it was released. In fact, it was actually a bit worse than Python 2 when it was out and those Python 2 users could continue enjoying loads of libraries to go with, and of course they knew how to navigate around Python 2's quirks so why bother. Sadly, this is still what I think of Python 3: "Why bother?".<p>Python 3 didn't have enough to warrant a 'v3', really: Python 3 could've just been Python 2.7 if it wasn't for the religious backwards compatility in Python, which, ironically seems to matter a lot. The syntactic and semantic differences weren't big enough that Guido couldn't have worked around the most important improvements into 2.x line and dropped less relevant stuff (like removing 'print' statement etc).<p>Even if Python 2.7 would've needed some changes to existing libraries, the psychological barrier would've been lower. It's about "Fixing my lib to work with Python 2.7 which is top of the line today" versus "Porting my lib to Python 3.0 which will be the official Python in a few years": guess which one sounds more appealing? Note that the amount of work in both cases wasn't that big.<p>I think mainstream Python will be 2.x till Python 4 is out.
I think many folks are reading too much into this. "Extended lifetime" is bug-fixes. The final planned release is 2.7.9 in 2015 - beyond that there will be source-only releases for major security problems. No new features, no non-critical bug fixes.<p>So this isn't really making Python 3 any less appealing. But the Python core developers cannot with a calm heart abandon all the users of 2.x, given the state of adoption today.
This is a result of some not so optimal design decisions in the past.<p>I remember, when Py3 first came out, everything was incompatible -- unnecessary incompatibilities like the u" notation for Unicode string literals that was dropped. Unnecessary incompatibilities in the C-extension-module implementation layer. And so on. The list of incompatibilities was just huge.<p>Later several of them where dropped, like the string literal trouble ... But than the trouble was already done. Many extension modules where not lifted to the new version, since the overhead was to big.<p>I think, many more projects would have adopted Py3, if more extension modules would support it.<p>The huge library of extension modules was always the strength of Python. Now we have many projects still running on Py2, because Py3 did ignore this strength.
Speaking as a Python outsider, this looks pathological. If backwards compatibility is such a big hindrance in switching from 2 to 3, why not ship a v2 legacy fallback interpreter along with the new stuff? If you wanted to make it fancy, you could even make a 3-to-2 bridge that allows people to run v2 code from v3.<p>Am I missing something here?
The best way would be to release a python 2.9 which incorporates most of the changes from 2 to 3 but the unicode change.<p>The Δ between Python 2 and Python 3 was just too wide. Even with breaking changes, with a small Δ people will just migrate eventually. Migrating projects drag each other over the "barrier" just like water in a hose can be sucked over a wall.<p>The issue definitely was not the print command, but other things such as ``iteritems()``, etc - by themselves not much to keep you from migrating, but there is a pile of these boring changes next to the big one (unicode).<p>I think Guido overestimated the appeal of the new unicode handling and underestimated how resentful people are to change. I figure that at least 1/4 of programmers are actually very opposed to each and every migration and a new version has to have enough incentives to counterbalance this built-in conservativeness.
I just got back into some Python programming after a 2+ year hiatus from the language.<p>I'm stunned that this 2.x vs 3.x debate is still happening and that 99% of all libraries in use<i></i>* haven't been converted to 3.x. I like the language, but ... damn... If it weren't for the scikit/numpy stuff, I'd stick with Ruby. The Ruby community seems much less fragmented and wants to see the language move forward. It helps a lot that the 800 pound gorilla, Rails, keeps up with Ruby releases.<p>edit:
<i></i>* By that, I mean that the conversion rate for commonly used libraries hasn't hit 99%.
This is the path that all dynamically typed scripting languages must follow. Over time, change becomes impossible because the lack of typechecking or static analysis tools means that any change might break something in a subtle and hard-to-diagnose way. And so the language grows by accretion. You end up with something like bash or perl, where there are a million ways to do any one thing. Each way was added at a particular phase of the language's life, and it could never be removed after that. And so the language becomes difficult to learn and unattractive to newcomers, so another scripting langauge pops up, and the cycle of life begins again.<p>Compare this to a language like golang, where you can just run "go fix" on your code to update it to the latest version. And you don't have compatibility hell, because when you distribute your application, it's a standalone binary. Stuff like go is the future. Get off the dynamic language hamster wheel.
I see many comments talking about how this will slow down the migration process. But I don't think the situation is that bad.<p>Most of the py3 wall of superpowers is now green (<a href="https://python3wos.appspot.com/" rel="nofollow">https://python3wos.appspot.com/</a>) with boto, mysql-python, nltk, python-openid being some of the rare few in terms of not having great py3 alternatives. And most of these have ports on the way already.<p>So one interesting effect of this is that now that there is some critical mass and people are starting new projects in python3, there is now pressure on package maintainers to have py3 ports. So it's users dragging the packages forward now rather than the packages dragging the users backwards.
Good news. They have another 5-6 years to recognize their mistake and cut Python 3 loose from Python, like Perl did with Perl 6. It's interesting how the same underlying mistake manifests itself in different cultures: Perl 6 was "we'll break all your code, but give you gonzo new features that we hope are useful." Python 3 was "we'll break all your code, but soothe some pedants and browbeat you into accepting the result."
The lesson here is that it's important to "sell" new versions of anything. You can't just expect people are going to upgrade because it's the new hotness. Older versions of your own software are often your biggest competitor. (See also: Microsoft and Windows 8).
To be fair, what was the reasonable alternative?<p>Cede control of python 2.x to vendors who continue to demand support and bug fixes?<p>That would be a disaster; it'd be a moment away from new features and a 2.8 'cant believe its not python'.
I just thought I'd like to know what Hacker News thinks.
Will Python 2.x ever die?<p>I'm still writing lots of code with it and even quite a lot of new code. It's been around for ages and it feels like almost no libraries have been ported to 2.x yet. On a couple of occasions I've started a project with Python 3.x just to drop it or move to Python 2.x as a library I need doesn't seem to exist for Python 3.x and I don't want to port it over myself. I've never had this issue with 2.x (no libraries support 3.x only.)<p>Most Python 3.x "killer features" have been back-ported to Python 2.x and I honestly feel little reason to upgrade myself now. When support for Python 2.7 is officially dropped we could fork it and continue. I would hope it wouldn't take huge amount of effort for some people to support it? Just fix bugs and security issues and take pull requests? In that way might Python 2.x even outlive Python 3.x or at least remain more popular?
The Python shop I used to work at, and this is a shop with some pretty big fanboys and apologists, wasn't able to upgrade because of library support, and these are people who would like to.
For reference's sake:<p>Python 2 was released Oct. 2000 and so will have a 20-year lifetime now. <a href="http://en.wikipedia.org/wiki/Python_(programming_language)#History" rel="nofollow">http://en.wikipedia.org/wiki/Python_(programming_language)#H...</a><p>Ruby 1.8, which was retired last year, had 10 years of life:
<a href="https://www.ruby-lang.org/en/news/2013/06/30/we-retire-1-8-7/" rel="nofollow">https://www.ruby-lang.org/en/news/2013/06/30/we-retire-1-8-7...</a><p>Obviously, version numbers don't mean the same thing...and Ruby 1.8.x to Ruby 1.9.x (or even 2.x) seems less of a jump than 2.x to 3.x.
I understand that changing to Python 3 can be expensive but really all that any company or person is doing is prolonging the inevitable. If they have a good product/app/etc. that will last it will have to change to Python 3 and sometime in the future, right? Why keep waiting? Why support something that is considered by it's makers to be inferior? I really would like answers to these questions, if someone is willing.
Years ago, when I first heard about Python 3 and plans to improve the language my first thought was "Yes! Multi-line lambdas are coming!", then I started reading more and found out that Guido actually wanted to _remove_ lambdas all together. I still remember the state of shock I was in after reading that, and a sinking feeling.<p>The lambdas stayed, fortunately, but, unfortunately, I'm still convinced the whole project was a bad idea. The cosmetic changes which make Python 3 incompatible with Python 2.7 are just not worth the trouble of breaking the compatibility. Has anybody ever tried to estimate the man-hours needed to port the myriads of great Python 2.7 libs to Python 3 and weight it against the advantages of subtle language improvements? I don't think so. Plus, the big Python's problems like GIL are still there in Python 3...<p>If it was up to me I would drop Python 3 and focus the development effort of the community on improving PyPy and porting libraries to it.
Wow I'm very disappointed. I keep making the effort to transition more to 3, but am frustrated to see so many dependencies only work with 2.7, and thus maintain both libraries. I am tired of this limbo.
This seems weird to me. Won't this cause a fork in Python at some point, where the 2.7 developers continue on 2.8 or rename it entirely, and another fork continues on what is now Python 3?
Since there still won't be a Python 2.8, I read this as the mainstream Python not evolving one bit for the next 6 years. For me, this would be grounds for moving to a different language.
Anyone know if RHEL 7 will ship with Python 3 in the base, even if not default? That could go a long way to boosting Python 3 adoption.<p>I know it's in SCL, but that lacks convenience for a lot of users.
I really thought this thread was a prank or joke when I saw the title. Sadly, it's not. The whole 2.7 / 3.x debacle is a large part of why I I have more or less stopped coding in Python and moved on to Ruby. The community is a large part of it as well.