3 ms·
> It's not a mistake. It's a... useful abstraction. It is specifially a abstraction that is not useful. > It's worth reading that document when deciding what
by a1369209993 7y ago
> It's not a mistake. It's a... useful abstraction.
It is specifially a abstraction that is not useful.
> It's worth reading that document when deciding what you think the "right" thing to do with "len()" is.
Technically not - the right thing to do is return the number of characters[0] - but the character segmentation parts are worth reading when deciding how to decode UTF-8 bytes into characters in the first place, so the distinction is somewhat academic.
> a [character] can actually be locale-dependent, what's two characters in one language may be one in another
[citation needed]; ch, ij, dz, etc are not examples, but I'm admitted not exhaustively familiar with non-latin scripts[1], so I would be interested to see what other scripts do.
0: or bytes, but that's trivial
1: Which is why I hate Unicode; I'd prefer to pawn that work off on someone else and just import a library, but Unicode has ensured that all available libraries are always unusably broken.
- joshuamorton 7y ago> Technically not - the right thing to do is return the number of characters[0] > 0: or bytes, but that's trivial In what encoding? The utf-8, utf-32, and utf-16 encodings of the same string are different numbers of bytes.
- a1369209993 7y agoNumber of bytes would apply in cases - like the len() of a python3 bytes or python str object, or something like C's strlen function - where you're not operating on characters in the first place. It's trivial precisely because there is no encoding. "\xC4\xAC" is two bytes regardless of whether you interpret it as [latin capital i + breve] or [hangul gyeoh] or [latin capital a + umlaut][not sign] ("Ĭ" / "곃" / "Ĭ").