Mikhail V writes:
That said, multiple methods is a valid option for the API.
Certainly I like the look of distinct functions more. It allows me to visually parse the code effectively, so e.g. for str.remove() I would not need to look in docs to understand what the function does.
OK, as I said, you're in accord with Guido on that. His rationale is somewhat different, but that's OK.
Just in some cases I need to convert them to numpy arrays back and forth, so this unicode vanity worries me a bit.
I think you're borrowing trouble you actually don't have. Either way, the rest of the world *needs* Unicode to do their work, and it's not going to go away. On the positive side, turning a string into a list of codepoints is trivial:
[ord(c) for c in string]
So I am just not the one who believes in these maximalistical "we need over 9000 glyphs" talks.
But you don't need to believe in it. What you do need to believe is that the rest of us believe that we need the union of our character sets as a single, universal character set. As it happens, although there are differences of opinion over how to handle Unicode in Python, there is consensus that Python does have to handle Unicode flexibly, effectively and efficiently.
Believe me, it *is* a consensus. If you insist on bucking it, you'll have to do it pretty much alone, perhaps even maintaining your own fork of Python.