3 ms·
I actually don't know why it's been such a big pain with Python 3. Ruby 1.9 also fixed the accurate handling of strings potentially encoded with multiple bytes
by bhaak 10y ago
I actually don't know why it's been such a big pain with Python 3.
Ruby 1.9 also fixed the accurate handling of strings potentially encoded with multiple bytes.
Fast forward to today, we didn't have such a turmoil like with Python and now, not even Ruby 1.9 is supported by the official devteam anymore. And there is nobody holding out on 1.8 anymore.
Compare that to Python 2 which will still be supported until 2020!
- dagw 10y agoOne big difference between Ruby and Python (and one of the big reasons that I think python3 failed to take off) is that the Ruby community has been much better at making sure that their major third party libraries are in sync with the core language. I don't remember the exact timeline, but basically when Ruby 1.9 came out you could more or less instantly start using it with RoR so there was no reason to wait with experimenting with it. When python 3.0 was released both django and numpy where still years away from getting official python 3 support into their releases so no one bothered to invest too much time into it, and this caused a major loss of momentum that is only today starting to slowly return.
- moduspwnens14 10y agoTo some extent, I think it's reasonable. PHP had the same issue (old libraries assuming single byte strings) and the way they handled it is pretty awful. Essentially all string manipulation functions also have an equivalent function with the same name prefixed with "mb_", which works for multibyte strings. The practical effect is that people use the default string functions and then things break when multibyte strings start showing up! It is backward compatible, but it's certainly ugly and that's quite a tradeoff.