3 ms·
> Unicode support and new style classes were in Python 2.7. Unicode support is tremendously easier in Python 3. You don't have to deal with the confusing encod
by canjobear 9y ago
> Unicode support and new style classes were in Python 2.7.
Unicode support is tremendously easier in Python 3. You don't have to deal with the confusing encode and decode stuff, and Python 3 strings have the right behavior in a lot of weird cases where Python 2.7 unicode objects do not.
Unicode support was my biggest reason for switching to Python 3, because I was dealing with natural language data with a lot of emojis and Python 2.7 was just an endless headache.
- mjevans 9y agoI actually argue that it's worse. In Python 3 you are FORCED to deal with unicode encoding; Python 3 does not react well with legacy data that should just be handled as is (without making things worse or incompatible). The alternative is to use a byte array without an encoding, which would be OK if Python 3 made coercion between the two easy (and had the concept of a 'validated' unicode string; operations known to keep a unicode string valid could leave that set, otherwise it would be 'not validated' but you wouldn't /need/ to care).
- zzleeper 9y agoThat prevents lots of mistakes. You only specify encodings while reading external data, and then everywhere else in your code you know you are dealing with strings and that's it (instead of your code working until a random Fóréígner trips it out)
- dbcurtis 9y agoWell, I spend most of my time dealing with internet and serial protocols, and the strict demarcation between unicode strings and byte strings is what keeps me sane. Explicit encode/decode calls are a feature, IMHO.
- Avernar 9y agoI wouldn't mind the strict demarcation if the internal format was UTF-8. Then a simple validate call on input would be all that was needed.