Somewhere in there must be my only time to use str.translate in any significant code:
I have used it a few times but I agree that it is not very intuitive or not exactly what is wanted. In the linked issue I didn’t really want to “translate” anything but just to remove some set of characters from a string. In fact I didn’t even want to do that: really I wanted to count the number of characters that were not in some set of characters but translate must have been the closest thing that I found at the time. I probably just looked through dir('') to see what might be of use but it’s an odd mix of possibilities:
capitalize casefold center
count encode endswith expandtabs find format format_map index isalnum isalpha
isascii isdecimal isdigit isidentifier islower isnumeric isprintable isspace
istitle isupper join ljust lower lstrip maketrans partition removeprefix
removesuffix replace rfind rindex rjust rpartition rsplit rstrip split
splitlines startswith strip swapcase title translate upper zfill
Out of these 44 methods I count about 11 that I use regularly. Most I never use. That could be an argument for adding more methods (why not? - the interface is hardly minimal). I am sure though that if I was maintaining the str class I would see it the other way around: we already maintain loads of methods that hardly anyone ever uses, please don’t add more.
This sort of thing is often said on these lists but frankly it is misleading at best. Firstly in the context above I wanted something that I could use in SymPy. Currently SymPy has precisely one hard dependency and that is mpmath which in turn has no dependencies and which is absolutely integral to SymPy’s core functionality. There is zero chance SymPy would add a dependency on some library to get this functionality even if it was pure Python (in which case it wouldn’t help anyway). Either this is in the stdlib or SymPy won’t use it.
Secondly a library with this functionality cannot become popular unless it has a lot more to offer. Even just for use in a single individual project that was not shared with anyone else I wouldn’t want to add a dependency for this. If the library had a lot more functionality to be of general use (e.g. like boost in C++) then maybe I would use it for some things. Otherwise though I don’t see how any library like this could become popular and then if it did the functionality would not “end up in Python core” because then the reply would be: just pip install python-boost if you want that function.
There is definitely a catch 22 here: proposals for additions to the stdlib are met with the suggestion to make a 3rd party package to see if it gains popularity. However I would never install that package but I might use the functionality if it was in the stdlib.