[Python-ideas] More user-friendly version for string.translate()

[Stephen J. Turnbull]

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.