4 ms·
I agree with the article that Python 3 has great character string handling, but I'd suggest that the author does not understand why people like Python 2's syste
by aeturnum 10y ago
I agree with the article that Python 3 has great character string handling, but I'd suggest that the author does not understand why people like Python 2's system.
Proper handling of unicode glyphs makes for a great demo and is clearly the proper behavior, but does not represent a common use scenario.
It's fairly rare to be doing sub-string manipulation of user input or strings that will be displayed. Instead, it's much more common to be transporting data around inside strings. Maybe you're moving some JSON, or some binary data or csv content. In this examples, you're moving data from one point to another and the Python 2 approach is far simpler. What encoding is it? Is it unicode? For most applications, it does not matter. You can put the data in a str, then pass that str to a function.
In Python 3, this scenario gets more complicated. Is your data in bytes? Is it in a str? If it's in a str, how is it encoded? The Python typing system does not make finding these things out smooth. The details will determine which functions you can pass the data to and what transformations you (may) need to perform. Python 3 makes the programmer work harder to pass properly-tagged string data to functions, which generally makes string handling code more finicky and complex. The result is a string system that is _much_ more predictable and understandable in the failure case, but is more verbose in getting there.
It doesn't help that Python's poor type management tools mean that your first indication you mis-handled a string in Python 3 is the same as Python 2 - unexpected output to a buffer (often b'string' instead of terminal-killing garbage).
- Sir_Cmpwn 10y agoYou shouldn't be moving things like that around in strings. You should be moving them around as bytes, then decoding them when you need to manipulate them. Your strategy is probably going to lead to subtly broken behaviors in your program. The problem here is not how Python 3 handles strings, it's how you're handling strings. >It doesn't help that Python's poor type management tools mean that your first indication you mis-handled a string in Python 3 is the same as Python 2 - unexpected output to a buffer (often b'string' instead of terminal-killing garbage). I agree, Python's behavior around implicit conversion of things to str is pretty bad. It would be better to throw a TypeError.
- aeturnum 10y agoThis is exactly what I mean. I know I should move binary data around as bytes. I'm not saying I want to (or intend to) move binary data around as strings. I'm saying that, in Python 2, you get a str - which happens to be binary and you don't have to worry about it. Even if it's unicode, it'll still work - it just won't matter. In Python 3, it depends on what the library gives you. Did it give you bytes? Maybe a str? You'll need to check and do the proper conversion to bytes. The behavior that Python 3 forces on you is safer and more correct, but it's behavior that you did not have to go through in Python 2. Sometimes, in Python 3, the library gives you bytes and you want bytes and you're fine, but it's common that you are not.