News for hackers. Stuff that matters.
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.