The problem is the definition of character in the context of Unicode text.
No, I fully agree with you with the definition of character in the context of Unicode text.
At issue is that reverse cannot recognise the presence of Unicode text. How do you think reverse can tell the difference between chr(113).chr(101).chr(769) and "qe\N{COMBINING ACUTE ACCENT}"?
It can either always treat the string as Unicode text, or never. Currently, it never does. To change that is backwards incompatible, so you'd have to demonstrate a bug in order to change that behaviour.
samples text
------- -------
current ok not ok
string ok not ok
unicode not ok ok
Your whole argument for the presence of a bug is that reverse uses "character" could be confused with Unicode's definition of the word.
One or the other is wrong: the behavior of the reverse function or the reverse function's documentation.
Those are the only two options if and if reverse's documentation uses the same definition of "character" as the Unicode standard.
Update: Added code. |