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.
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.
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.
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.
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.
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.
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.
[0] http://www.kalzumeus.com/2013/06/17/if-your-business-uses-ra...
> 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.
Note that 2.6 had no installers released beyond 2.6.6 (2.6.9 was the eventual last release), so there's a precedent for source-only releases if nobody does want to provide Windows/OS X installers.
10 years actually. This is a common misconception from those who do not read the lifecycle page carefully.
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!
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.
I assume there is a good answer for switching to Python 3, but I honestly don't know (haven't bothered to do any research though).
Harshly put: I care about getting my python script working as soon as possible and for a foreseeable future - I couldn't care less for the Python language and it's future.
This bothers/worries me, because I don't understand where this notion that "learning Python 3" requires significant effort or commitment comes from. Python 3 isn't massively different from Python 2. I learn more "new stuff" (APIs I've never used before, implementation details of systems I work on/with, etc.) basically every month than that difference.
Python 2 -> 3 can be a big step because of dependencies. The difference between the languages themselves is negligible (and yet, IMHO for the better). You don't need to learn any new ways of thinking here.
If you're comfortable with Python 2, you're comfortable with Python 3 as well. If your dep ducks are in a row and you're writing new code, it's an obvious choice.
Guido just created a bigger problem. No good deed goes unpunished.
Unicode
And of course, you'll move from a platform that's shutting down to one that's evolving
Really, it's worth it.
Now If I had stayed on 1.2, then many of the extra libraries I am using or looking at these days would not be compatible. (Now sometimes I want to use older libraries that have not been kept up to date, but the more popular packages which gain traction - the "more important ones" tend to keep up to date or replaced by ones that do).
A language is different from a framework, but I assume once enough traction is gained, then the same thing will happen with Python - popular packages will end up up on Python 3 only. There seems to be a fair bit of 'push' from the community for people to move to Python 3, with comments of "why not change already".
- "Ugh, that thing is lacking/stupid/messy."
- "Oh, no problem, that wart has been fixed in Python 3"
- "Can we use it?"
- "No."
I'm not sure if it was something I did but I also occasionally found that when pip'ing Python 3 libraries with a lot of dependencies, occasionally some of them would actually be Python 2 libraries and things would break.
Your argument is right, but they should have thought about that before fracturing the python community.
In what way is python 2 more convenient to write? Outside of the rapidly shrinking set of cases where the best approach to a key problem is addressed by a Py 2 only library -- or the case of "I want to deploy on Google App Engine" -- I don't really see how Py 2 is "more convenient".
This isn't disappointing, it is refreshing. Python is dead, long live Python.
But, I have to say, that during the keynote by Guido this morning, this was more-or-less the sentiment that I was left with, but with a #positivepython-twist.
Listening to Guido, I left with the inspiration to try and help this community make that migration.
I hope that, by this time next year, I can have made some contribution to the community that will help people such as the GP be in a position to use "the latest and greatest".
Here's the list, let's make it green:
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?".
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).
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.
I think mainstream Python will be 2.x till Python 4 is out.
It still has a few things that really suck!
The thing that bothers me the most is the removal of in-argument tuple unpacking. For example, in python 2.x you could write:
dist = lambda (x1,y1),(x2,y2) : math.sqrt((x1-x2)2 + (y1-y2)2)
Whereas in python 3.x you must write
dist = lambda p1,p2 : math.sqrt((p1[0]-p2[0])2 + (p1[1]-p2[1])2)
Which is just awful to read. It gets much worse when you're trying to program in a functional style and you are using triples or quadruples. Imagine using "x[1], x[2], x[3], x[4]" instead of something like "length, width, height, color".
PEP 3113 attempts to rationalize this change, but it's kind of an awful PEP. It claims "no loss of abilities removed", which is clearly false, and the proposed benefits are highly specious. The entire tuple-unpacking system could just be reduced to the insertion of an unpack instruction at the start of the function. That would actually make a lot of sense with Python's policy of "ask forgiveness rather than permission", since trying this with the wrong tuple length would throw a ValueError explaining what went wrong.
I also miss (but it's not really an important language feature like in-argument tuple unpacking) the ability to do encoding directly on strings. For example,
"hello".encode('hex')
or
"aGVsbG8=".decode('base64')
That was much more convenient than having to import some library and use library methods.
I agree with the sentiment, and 3.2 had some rough edges still, 3.3 is better and 3.4 finally gives a virtualenv similar (or even better) to Python 2
The Unicode switchover is where all the pain is, and it isn't particularly clear that there is a good way to do such a thing.
But least for smallish scripts which print a lot it give you a better overview because the print line look different than other lines. Sometimes prints can almost be like comments.
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.
And if I look at the whole thing now, "no new features" is not certain. If people are still unwilling to switch he may consider backpedaling and backport some other features to 2.X.
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.
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.
I think, many more projects would have adopted Py3, if more extension modules would support it.
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.
I mean a hard difference between a string and bytes and strings being utf-8 by default seem to be a necessary (and good) reason?
Am I missing something here?
Then, without the fancy v2-to-v3 bridge, it wouldn't really be more useful than just having both interpreters installed separately.
The fancy bridge does sound like a cool idea. We can run Python 2 or 3 code from Julia (with limitations on the data passed between them), so why can't we run Python 2 code from Python 3, with the same limitations?
It's basically possible already with some RPC libraries, but the experience could certainly be streamlined.
Maybe py3 just doesnt have good enough features compared to 2 for people to make the switch and shouldnr have existed in the first place?
But gradually introducing changes.
Now python is for all intents two languages instead of one.
Python2:
print(1/2 * 1000) # 0
print({b'a': 'bytes', u'a': 'text'}[b'a']) # text
print(b'A'[0]) # A
print(1/2 * 1000) # 500
print({b'a': 'bytes', u'a': 'text'}[b'a']) # bytes
print(b'A'[0]) # 65
#! /usr/bin/env python2
vs
#! /usr/bin/env python3
Python allows you easily to run different versions side by side. There's really no good excuses.
Red Hat is major reason why the migration is so tough. They still ship with Python 2.6.
The problem with 2.x scripts is that they mix characters with bytes quite often. This is not something that you can easily fix by a program, because from this perspective 2.x programs are broken and need to be fixed.
What you are suggesting is already available, python 2.x and 3.x can be installed and work side by side without any issues. There's even 3-to-2 conversion tool (converting backward is much easier than the other way since python3 is more strict).
The problem really comes down to distribution maintainers, for example we are talking about Guido extending support from 2015 to 2020 for Python 2.7. So before this announcement, Python 2.7 would no longer be supported in 2015, yet we have geniuses at RedHat still shipping it with Python2.6.
And no, there is no incompatibilities between 2.6 -> 2.7 as there's from 2.x to 3.x
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.
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).
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'm stunned that this 2.x vs 3.x debate is still happening and that 99% of all libraries in use* 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.
edit: * By that, I mean that the conversion rate for commonly used libraries hasn't hit 99%.
You kind of answer your question you know, the reason why Python is so fragmented wrt Ruby is precisely because it has a much larger number of uses case: scientific (numpy/scipy/panda), sysadmin, web (django, bottle, ...), games (Ren'Py, ...), etc. Ruby on the other hand is pretty much just Rails[1]. It doesn't make Ruby a bad language, but then it's a lot easier to handle the migration.
[1] Yes, Ruby can also do games and statistics, but AFAIK, it's nowhere near as much used as numpy is to Python.
Also don't ignore that Ruby has a _huge_ subcommunity in asia that you rarely get any news from, using the language for many other things.
Still, an aggressive push towards the future is part of the Ruby mindset. If your lib doesn't work with Ruby 2.1, it is not considered maintained. That helped _a lot_ during the 1.8->1.9 transition, which was basically Rubys Python 3 moment. The Ruby community managed to cross that bridge.
Puppet and chef say hi.
The worst thing to me about this transition is what it says about updating existing languages. Python 2 to 3 wasn't that large, really, and look at the resulting screwup, still ongoing. I was on the pro-Python 3.0 side (though I had 0 influence on the decision) and honesty compels me to admit that I never dreamed that it would go down like this. I never would have been pro-3000 if I'd known.
Anyhow, to anyone who has ever read about Go or Clojure or Nimrod or Rust coming out and asked "Why do we need another languge?", the answer is: "Look at Python 3." If you want to tweak anything about an established language, it's almost easier to "just" bring up an entire new language and stack than to fix the old one. And unless our existing languages are Practically Perfect in Every Way... and they're not... we need fixes, which means we need new languages.
So maybe it's only when you want to do something as invasive as switching the default string type that things go so sideways, if that is even the right description for Python 3 (which I think you could argue was really about having a better language available in 2015 or 2016 or so, not just being the Python after 2.7).
As far as specifics, one of the first tasks I wanted to perform was to survey some of the NoSQL databases with some test cases that I would build in Python.
Mongo had a good 3.x driver and I worked with it. Great... but then these drivers all put me into a brick wall trying to use 3.x: couchdb, pycassa, happybase, and cql. There were numerous others that I tried along the way, but I don't have notes on all the failures.
Now, rather than trying to be 3.x pure, I don't even bother checking. I'm just using 2.7 for this project.
My organisation has a massive internal platform, with hundreds of applications all developed in Python 2.6. We are in the process of upgrading the base platform to 2.7 but I believe we will never be able to upgrade to 3.x. We have hundreds of thousands, perhaps millions of lines of Python code and it's growing all the time. When we started the project version 3 wasn't really a practical option.
Yes, the Ruby 1.9 release broke backward compatibility and there was quite a time when lots of Ruby stuff was stuck on Ruby 1.8 and you saw much the same stuff as Python 2 to Python 3.
Indeed, one of the big issues was a major change in string handling (to encoding-aware strings), just as with Python.
It resolved more quickly, but I think that's largely due to the fact that Ruby had less diversity of libraries that were critical in one domain or another than Python, and thus less holding it back from changing over. Python has been something of a victim of its own success here.
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.
It seems to be that automatically upgrading your code, even with "go fix", is staying on the hamster wheel. Using a stable language like Python 2.7 is getting off the hamster wheel, since the "hipster" programmers (including me, sometimes) have moved on.
So in a way, Python 3 helps you if all you care about is stability, since people will make changes to 3 and you can keep using 2.7.
There is also the issue of how code gets installed on the system. The Python model is that you have a bunch of py files sprinkled throughout the filesystem. In this case, you have a "baling out the ocean with a teaspoon" issue when making a major change. There has to be a flag day when everything changes at once. In contrast, with Go, I can have apps compiled with Go 1.0, Go 1.1, and Go 1.2 co-existing happily on the same system. They don't share library files. (Yes, I understand abut things like virtualenv, but that doesn't help distributions that want to ship your software.)
A big part of why Sun (and now Oracle) has been so conservative about backwards compatibility in Java proper (as opposed to the libraries and ecosystem) is because JDK upgrades have a similar "baling out the ocean with a teaspoon" property. It's all or nothing... you generally only have one version of Java installed, and it has to play nice with everything. If they had integrated the runtime into the binary like Go did, this would be much less of an issue.
What I am saying is that it wasn't much prettier in those cases, and golang might not have had the same type of issues yet, but it just hasn't been around for all that long.
Java hasn't really acquired that much "cruft." The cruft that it does have is mostly relics of really poor design decisions that were made (again) on day 1. For example, the decision to support thread cancellation, which the designers later realized was dumb, has left a bunch of defunct APIs in the Thread class which you're now not supposed to use. I already talked about how the need for jar compatibility (due to the misguided portability religion) led to the generics issues. Java is an ugly language in some ways, but you can't really say that it degenerated: it was that way from the beginning. In fact, now is probably the prettiest it's ever been (not saying much).
Could dynamic languages avoid this by having (say) a byte-code compiled backwards compatibility module? I would imagine it looking something like this for Lua:
luac -version=5.0 module.lua -o module.o
and then call into whatever functions you need from module.o in the rest of the project, using the new interpreter for whatever doesn't need to use legacy features.
Most of the py3 wall of superpowers is now green (https://python3wos.appspot.com/) 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.
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.
The list is still too long.
https://pypi.python.org/pypi/paramiko/1.13.0
Fabric won't be far behind after this.
I suppose they're not officially releasing it because there may be some unloved corners of the library that don't work yet on Python 3. But everything I've done with it has worked fine.
Issues that prevent a release are not related to Python 3: check https://github.com/nltk/nltk/issues?milestone=2&state=open, https://github.com/nltk/nltk/issues?milestone=3&state=open and https://github.com/nltk/nltk/issues?milestone=1&state=open.
PHP 4 to 5 was a massive leap compared to Python 2 to 3, but they actually made that leap!
He didn't take the decision lightly. These are just two examples, but there's still lots of big Python 2.x uses out there.
If it's any consolation, his keynote started with a big "forbidden" sign over "2.8".
However, nobody noticed because nobody used the OO features in PHP4.
There were a few reasons why they pushed harder with PHP5 however, especially given the tendency of budget web hosts to use old versions of PHP4 with insecure by default configurations (register_globals etc.).
That may have been true of Python 3.0 vs. 2.x, but Python 3 has moved forward quite a bit since 3.0.
If I switch to anything, I'll probably switch to Go.
(I originally typed 2.7, which is nonsense.)
Python 3 compatibility far outnumbers incompatible packages now: http://python3wos.appspot.com
It's not like I can just decide to drop the dependency on boto and twisted from all my work code and migrate to something else.
I understand that these are opensource projects and I should be submitting patches to make the migration faster, but from a business point of view, I have absolutely nothing to gain by doing that instead of just sticking with 2.7.
People won't leave Python 2.7 for Python 3.x, they'll go to other languages. Python has no right to its users.
I don't know what you mean by "I didn't find it simple ....". I googled "python 2 und 3 differences", and that was the first result.
Cede control of python 2.x to vendors who continue to demand support and bug fixes?
That would be a disaster; it'd be a moment away from new features and a 2.8 'cant believe its not python'.
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.)
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?
My guess would be that Python 2.x will die at the same time that Python dies, i.e. the "transition" to Python 3 will never really happen, and part of the reason that Python will die is the split between 2 and 3.
I don't think it was obvious that Python 3 would "fail" in this sense, but it seems pretty likely now. Sympathy with Guido; this is essentially a cultural problem rather than a technical one, but as a rule backwards-compatibility tends to be a key component of success as a programming language (or library, or even O/S) evolves.
It's not too late -- a compromise could be found, but it would essentially involve abandoning 3 to a large extent. Not very palatable.
I'm sure Python has many years to go though, so I wouldn't worry about writing new code for the moment. Keep an eye on how things develop and think about jumping to another language if no-one sorts out this mess.
I personally won't be moving till GAE, Azure, Amazon, PyPy, PyInstaller, and all Linux distros make the jump. Which at this rate appears to be never.
I'm going to do exactly what you're suggesting, and move off of Python entirely at some point. I'm truly amazed that GVR is dancing with death to kill Python over unicode and cruft. I'm hoping Python (2) becomes the community version and 3 remains the experimental branch.
Python 2 was released Oct. 2000 and so will have a 20-year lifetime now. http://en.wikipedia.org/wiki/Python_(programming_language)#H...
Ruby 1.8, which was retired last year, had 10 years of life: https://www.ruby-lang.org/en/news/2013/06/30/we-retire-1-8-7...
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.
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...
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.
I don't think it's entirely fair to call people who don't upgrade lazy or scared. However, it's really not that hard at all these days. Most packages are ported, and there are many success stories who have documented all the hard bits.
Who knows where 3.x will be in 6 years, but now a huge number of people will continue to develop in the 2.x series with no worries. Six years feels like a long time when you're at the beginning of them. By the end, maybe it will be easier to just tweak the Python 2.x codebase than switch everything to 3.x.
No, what it is is "legacy Python 2.7 gets 5 more years where bugfixes that we expect certain major users of Python -- notably RedHat, which has 2.x bundled into releases that have long support terms -- to submit may be published to the world as bugfix (2.7.x) releases".
The mainstream of Python development has been 3.x for years, and that line will continue to keep evolving.
I'd never heard of Guile until you mentioned it. I looks like Scheme. If moving to a lisp-like language, Clojure, which you mention, would be a better choice. It's backers claim they'll be there for the long-term, and it has innovative concurrency constructs.
As for Groovy, it appears to be dying. Oracle went to a lot of trouble to create Nashorn, a zippy Javascript bundled with Java 8, and you can bet they'll be promoting it heavily in the "scripting Java" space to dislodge Groovy. Grails is losing adoption bigtime, getting replaced by Node.js, Play!, Django, and even Rails. When Gradle upgrades to version 2, they'll likely bundle some other JVM languages for their API, e.g. Nashorn.
I know it's in SCL, but that lacks convenience for a lot of users.
https://access.redhat.com/site/documentation/en-US/Red_Hat_E...
I contribute back to the community and I take the time to make sure my open source code works with both Python 2 and Python 3, but I will not drink the kool-aid. Not even for upvotes on HN ;-)
Slashdot has always highly valued humor. "+5 Funny" is a highly sought after moderation. So, perhaps in reaction, HN usually downvotes attempts at humor.
Neither approach is "better". It's just how the respective communities have evolved.