3 ms·

>There are plenty of uses for getting the length of a string where you will not be running into combining characters, clusters or any other things which would r

>There are plenty of uses for getting the length of a string where you will not be running into combining characters, clusters or any other things which would require special handling. How do you know that? Any user supplied text may contain those things. >remember that on the internet, all the data you receive is initially in string form It's not. It's bytes. >very often we want to receive data representing fixed-length values such as phone numbers or credit card numbers This is a good example of why strings shouldn't have a length property - people don't understand what length actually does in most languages. If you think that a len() function can verify that the contents of a text field is in the format of a CC number then you don't understand the len function. It can't do what you are asking. See the examples given in the GP (len("\u0301") for example). The fact that the people who advocate for length functions want to use them for things that they are broken for is exactly why length functions shouldn't exist.

ubernostrum 11y ago
How do you know that? Any user supplied text may contain those things. Which is why, in addition to things like length checks, we use other checks. But length is a quick and easy check for many types of values, and should be supported. I've been down in the depths of Unicode behavior a time or two. I know what lurks down there, and I know from experience that your "strings should never allow these operations" stance is just as dumb as the more-common "I don't know what Unicode really is" stance. Can length checks and slicing and other operations run into trouble in some corners of Unicode? Sure. But if "this might cause trouble" were grounds for forbidding programmers ever to do something, we wouldn't have computers, any useful software at all, the internet or most of the other things we like and take for granted despite the fact that we occasionally have to fix bugs in it. Now, get down off your snobby horse and join the rest of the real world, where we know that something might not be guaranteed reliable in all logically-possible cases, but find ways to work with it anyway because in 99.99% (or more) of the cases our code deals with it's good enough.

ubernostrum 11y ago

How do you know that? Any user supplied text may contain those things. Which is why, in addition to things like length checks, we use other checks. But length is a quick and easy check for many types of values, and should be supported. I've been down in the depths of Unicode behavior a time or two. I know what lurks down there, and I know from experience that your "strings should never allow these operations" stance is just as dumb as the more-common "I don't know what Unicode really is" stance. Can length checks and slicing and other operations run into trouble in some corners of Unicode? Sure. But if "this might cause trouble" were grounds for forbidding programmers ever to do something, we wouldn't have computers, any useful software at all, the internet or most of the other things we like and take for granted despite the fact that we occasionally have to fix bugs in it. Now, get down off your snobby horse and join the rest of the real world, where we know that something might not be guaranteed reliable in all logically-possible cases, but find ways to work with it anyway because in 99.99% (or more) of the cases our code deals with it's good enough.