Re:A viable solution for Python concurrency
by garmaine on Friday October 15, 2021 @11:23PM
(#28885289)
So? `.decode(“hex”)` still makes sense on a string, and was >95% of the encode/decode calls I had.
Re:A viable solution for Python concurrency
by rtpg on Saturday October 16, 2021 @01:43AM
(#28885819)
Hex-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).
Re:A viable solution for Python concurrency
by garmaine on Saturday October 16, 2021 @05:35AM
(#28886633)
That’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.
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.