Imagine someone who was used to doing something like this:
import string
list=open('foo.txt').readlines()
list_strip=map(string.strip,list)
And then discovering this no longer works because the strip function has been removed from the string module (and moved to the string object). If all they want to do was a quick read of a file and then parse - they are not going to dive into Python3 and figure out the new way to do it - they'll just stick with pythonv2.It does, on the other hand, break backwards compatibility. Which is why hardly anyone updated.
When I decided to use pelican for a non-English blog, I thought it would be piece of cake; just changing the theme and plugging a calendar converter and I would be done with it. In reality, I had to fork pelican and the calendar library (which was not well-maintained) and bang my head to the wall for three days to make them work together, all because of the whole string/unicode seperation and the fact that things work automagically as long as you're just using ASCII.
I like the explicit separation that Racket has between "here is a buffer of binary data" and "here is a sequence of Unicode characters," and (looking on the outside without working with it), I'm glad that Python 3 began to adopt some of that.
In Python 2, it's really easy to write code that confuses bytes and characters, which introduces bugs and crashes when non-ASCII characters show up.
In Python 3, they made it easier to work with Unicode, because it's the default for everything, and much harder to confuse bytes and characters, because of that separation between the data types.
When Python 3 started out, it had almost no libraries. So most projects at the top of the software stack couldn't use Python 3 because all the libraries they needed only worked with Python 2.
Below the top, to this day any individual library that wants to switch to 3 basically has to maintain separate forks for 2 and 3, because a lot of downstream users still use 2 because not all libraries are 3-compatible yet.
I think the Python developers are crazy for not using the proven __future__ import mechanism to allow new features to be introduced gradually and have new code interoperating with old code.
Change is hard. People don't want to spend the money on upgrading. It's almost all downside with very little upside.
Don't ever upgrade a running system until you are forced to do so.
http://lucumr.pocoo.org/2013/5/21/porting-to-python-3-redux/
Yes.
> Or is the Python community just very reluctant to jump on new things?
In my experience no. Lots of features have been added over the years, and they seem to be adopted quickly. v3 is a really big change though.