3 ms·

I would suspect that you don't deal with much non-ascii data if you like python3's string handling. In Python 2 you have control over encodings. You can work wi

by krick 11y ago

I would suspect that you don't deal with much non-ascii data if you like python3's string handling. In Python 2 you have control over encodings. You can work with unicode-strings internally, but you receive and produce bytes, which is actually the only truth in the computer world. Everything else is a lie. It would be nice to pretend that there's only 1 encoding in the world and that encoding is roughly equivalent to unicode itself, but this isn't true. World doesn't work on UTF-8. By abstracting encodings Python 3 obscures what's actually happening.

zo1 11y ago
Not at all, it forces you to unify to storing character data as Unicode code-points. Eventually if you go down far enough, you're reading the raw bytes you speak of from some sort of external system/file/DB. It's at that point that you define your encoding, and never worry about it every again. Except for when you touch those external systems/files again, again with full knowledge about what encoding is required. Either way, if you're not dealing with differently encoded character data in Python 2.x as noted above, you're causing yourself some unnecessary headaches.
vetinari 11y ago
In Python2, I couldn't just print the string I just read from file - such were the joys of Windows console, which has different encoding than the rest of the system (cp85x in console, cp125x in filesystem & gui)... Compared to that, Python3 was like gift from heaven.
takeda 11y ago
Something tells me you did not experience the pre-unicode world around 90s. I did, and I didn't like it. I prefer it is abstracted from me thankyouverymuch. But seriously, all what python (and as a matter of the fact majority of languages) is placing a clear distinction between a byte and a character. This forces developers to keep in mind what they are dealing with and reduces number of bugs. The truth is that if you treat everything as bytes, chances are that your program has bugs. Actually good test is to convert your existing Py2 code to Py3, if you have encoding/decoding errors then your code was buggy.
- Avernar 11y ago
  > But seriously, all what python (and as a matter of the fact majority of languages) is placing a clear distinction between a byte and a character. No, they make a clear distinction between bytes and code points. This is the wrong approach as code points are not characters. People are going to think that everything is fine now that they're using code points and the unicode type when they should be using a unicode library for text manipulation.

by krick 11y ago

zo1 11y ago

Not at all, it forces you to unify to storing character data as Unicode code-points. Eventually if you go down far enough, you're reading the raw bytes you speak of from some sort of external system/file/DB. It's at that point that you define your encoding, and never worry about it every again. Except for when you touch those external systems/files again, again with full knowledge about what encoding is required. Either way, if you're not dealing with differently encoded character data in Python 2.x as noted above, you're causing yourself some unnecessary headaches.

vetinari 11y ago

In Python2, I couldn't just print the string I just read from file - such were the joys of Windows console, which has different encoding than the rest of the system (cp85x in console, cp125x in filesystem & gui)... Compared to that, Python3 was like gift from heaven.

takeda 11y ago

Something tells me you did not experience the pre-unicode world around 90s. I did, and I didn't like it. I prefer it is abstracted from me thankyouverymuch. But seriously, all what python (and as a matter of the fact majority of languages) is placing a clear distinction between a byte and a character. This forces developers to keep in mind what they are dealing with and reduces number of bugs. The truth is that if you treat everything as bytes, chances are that your program has bugs. Actually good test is to convert your existing Py2 code to Py3, if you have encoding/decoding errors then your code was buggy.

Avernar 11y ago
> But seriously, all what python (and as a matter of the fact majority of languages) is placing a clear distinction between a byte and a character. No, they make a clear distinction between bytes and code points. This is the wrong approach as code points are not characters. People are going to think that everything is fine now that they're using code points and the unicode type when they should be using a unicode library for text manipulation.