3 ms·
> So, years later, the only thing I'm surprised at is that Python 3 actually caught on to the extent it did. Well, it's been over 8 years. And we've just reach
by ProblemFactory 10y ago
> So, years later, the only thing I'm surprised at is that Python 3 actually caught on to the extent it did.
Well, it's been over 8 years. And we've just reached the point where nearly all libraries are available in Python3, and Python3 is recommended for starting new projects.
Python3 was also a very unconventional backwards incompatible change. 90% of the incompatibility came from "you must correctly and carefully handle unicode vs bytes". All other backwards incompatible changes were trivial in comparison, almost fixable by search and replace.
And "careful handling of unicode vs bytes" was something that you already could do in Python2, and should do in Python2, but weren't forced to. If you did, then upgrade to Python3 was easy. If not, then you had a massive testing and refactoring problem on your hands.
I would not even see it as a language change, but would compare it to C and C++ compilers turning -Wall -Werror on as mandatory flags in the latest release. It would be sort of "good for the ecosystem" in the long term, but would also be a lot of effort for people with legacy codebases.
- saurik 10y agoThe fact that you could choose to be that careful with Unicode in Python 2.7, though, is important to not forget: if the only change was that now you had to be, then code could have easily migrated and worked on both. This was the story of Ruby 1.9, which was, compared to Python 3, a cakewalk. The reality here is that you are just wrong in both understanding and premise :/. First, all these minor changes are actually extremely serious, as they made it hard to impossible to have cose which ran on both; as someone who was nowhere near an expert in Ruby, it was still easy to write code which straddled the boundary between 1.8 and 1.9. Ruby 1.9 really could be seen as a set of "warnings" on 1.8. Second, the most serious change in Python 3 was not Unicode, it was actually the way it handled generators and iterators and lists in various contexts: this was a set of changes which broke lots of code in subtle ways and which could not be handled using your argument of search and replace (and which contributed to the awkwardness of having code running on both 2 and 3 at the same time).