It seems like I've been reading about the difficulties of Python V2 -> V3 for awhile. Why is that? Is this Python upgrade unusually difficult/ambitious? Or is the Python community just very reluctant to jump on new things?
For the casual user, Pythonv3 is in many way backward incompatible and, for those type of users, who know python V2, and were happy with it, and whose full time job was something else - learning a new version of the language, particularly one without all the supporting libraries of pythonV2, didn't really have much return on investment.
Imagine someone who was used to doing something like this:
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's a big, ambitious update. The biggest difference is forcing users to distinguish between strings and byte sequences; essentially programs now have to be encoding-aware (at least if they use any of the standard library functions). Which is a Good Thing, but can require a ton of work for existing codebases.
Maybe not in the world of ASCII, but the new Unicode system scream seems pretty loud to me.
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.
smnrchrds's case of fixing someone else's ASCII assumption gets easier, because the code probably would not have been written that way.
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.
I've seen many programmers having trouble with this. But it's essential when using UTF-8, because sgtring presentations length might be is different from byte length. So byte != char != int (0-255). It's hard to get for some coders who are used that all of those datatyps are the same.
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.
In Ruby world, some people are still on 1.8.7, even though it was end-of-life'd in June, and it was known that it would be on that date a few years before.
Change is hard. People don't want to spend the money on upgrading. It's almost all downside with very little upside.
Imagine someone who was used to doing something like this:
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.