4 ms·
`.decode` doesn't work on strings because you decode bytes! PYthon has UTF strings! I agree about the annoyance of the codec modules, and stuff like the urllib
by rtpg 5y ago
`.decode` doesn't work on strings because you decode bytes! PYthon has UTF strings!
I agree about the annoyance of the codec modules, and stuff like the urllib reorg happening on 3.0 instead of shifting it to later releases (and self-owns like the u prefix). But if you're calling `decode` on a string you have a bug in hiding, from the moment that your "code that handles encodings transparently" blows up when someone gives you a file that isn't UTF-encoded.
signed: someone who did the 2 -> 3 transition for a project that deals with a lot of non-UTF-stuff.
- garmaine 5y agoSo? `.decode(“hex”)` still makes sense on a string, and was >95% of the encode/decode calls I had.
- rtpg 5y agoHex-encoding works off of bytes… like if a character has a different byte representation between two encodings you need to specify in both directions Even the Python 2 strategy for hex might lead to your text getting garbled if you’re using anything not représentable in ASCII (roughly).
- garmaine 5y agoThat’s not what decode(“hex”) does though. It takes strings in whatever encoding and turns 0-9,a-f into bytes. In Python 3 it would presumably return a bytes object instead, which you could then hypothetically call encode(“hex”) on. But the point is that it would have kept the syntax the same even if the underlying types changed. Python3 unnecessarily broke compatibility in many places. Yes I agree that using bytes.fromhex() and .hex() are better design choices. But requiring manual inspection and updating of all strong manipulation code for the transition was an outrageous requirement, particularly for a dynamic language that doesn’t (or at least didn’t at that time) have compile-time type checking to catch such errors.