# Nicer interface for str.translate

**URL:** <https://discuss.python.org/t/nicer-interface-for-str-translate/30434>\
**Category:** Ideas\
**Created:** [July 28, 2023, 9:53am UTC](https://discuss.python.org/t/nicer-interface-for-str-translate/30434 "2023-07-28T09:53:58Z")\
**Posts on this page:** 1\
**Showing post:** 20

<div class="post-metadata">

**Author:** ![encukou](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/encukou/32/2461_2.png) [@encukou](https://discuss.python.org/u/encukou)\
**Post date:** [August 3, 2023, 12:55pm UTC](https://discuss.python.org/t/nicer-interface-for-str-translate/30434/20 "2023-08-03T12:55:03Z")

</div>

> [@kknechtel](#):
>
> But on the other hand: if not that, what **was** it intended for? (And why does the C implementation do the things it does?)

The use cases you mention (with Django/Torch), and possibly some more. If you want to do some more archaeology, you might want to look at the Unix `tr` command; it looks to me like `translate` was inspired by that.

For things like replacing unwanted characters with underscores, in C back in 1999, a lookup table with (up to) 256 bytes would be the obvious choice. It wouldn’t need an explanation. The story of it becoming esoteric is quite interesting; thanks for digging up the Python leg of the journey :‍)

Nowadays, maybe we want something like [teaching `replace` to do multiple replacements](https://discuss.python.org/t/making-str-replace-accept-lists/4144/15) instead. It seems that limiting the matches to _single_ characters isn’t particularly important.  
Of course, `multireplace` has its own issues.

---

_[View the full topic](https://discuss.python.org/t/nicer-interface-for-str-translate/30434)._