Currently, str.removeprefix and str.removesuffix only accept str argument.
I propose allowing tuple in the same manner as str.startswith.
References:
What should it do if you write s.removesuffix(('a', 'ab')) or s.removesuffix(('ab', 'a'))? Are the given suffixes ordered?
Yup, ordered. Remove the first one found.
This would be in line with how string search usually works for multiple patterns.
Also, in line with how “swappable” multi-string str.replace would look like. See: Feature Proposal: Multi-String Replacement Using a Dictionary in the .replace() Method - #21 by dg-pb
1 Like
Just to correct myself. String search does not “usually” work like that. But Python’s regex-directed search does work this way. And also, slow moving idea to add str.find(tuple) would do it in the same manner as well.
This case is simpler and analogy is not necessary (but I find it comforting that things are consistent).
These methods do not work like str.strip, which iterates and trims as long as none of the characters match anymore. These methods just remove prefix/suffix once. So this extension would be in line with this:
'aaab'.removesuffix(('ab', 'b')) # 'aa'
'aaab'.removesuffix(('b', 'ab')) # 'aaa'
Do you have a common use case for it that isn’t already covered by urlparse.parse.urlsplit (for removing protocol from URLs), os.path.splitext (for removing file extension names) and str.rstrip (for removing trailing newlines)?
My own use-case that I have just encountered is extracting code from markdown. E.g.:
a = """
``python
code
code
``
"""
code_string = a.strip().rstrip('`').removeprefix(('``python', '``py'))
Not sure about common. Just thought to post it if others have some use-cases as well.
Given str.strip and str.removesuffix/prefix were deemed to be useful, thought that this extensions might be useful as well.
And this extension does seem natural to me, I can’t see any alternatives that this would obstruct.
Also, with this would be easier to write “multi-strip” function.
Also, I don’t think I would have posted this if this wasn’t recent: Pre-PEP: str.ensureprefix str.ensuresuffix
Just thought it is good time to consider this as well as we are at it. 
It seems like almost every week or two, you propose to expand Python’s API. At the heart of each of those seems to a premise that it would be too much to ask to write a simple for-loop.
Personally, I think there should be a strong principle of parsimony. Does the user base actually have a pain point here? Would it save more than a line or two in a real code base? How many string methods and signature variants are too much? Do we really need this. I think not.
2 Likes
Hmm but how do you get the value of a in the first place? Chances are that the code block is extracted from a larger document with regex or some markdown parser, which, as you can tell, can already be made to extract what’s inside the code block prefix and suffix just as well. Also, chances are that you want to remove code block prefixes of any language, not just Python, so a regex or parser would be preferred anyway.
My point is that in almost all cases I can think of where there is more than one possible prefix or suffix it’s better to use regex or a domain-specific parser.
2 Likes
Note that the PEP does talk about tuple support (in the “Rejected Ideas” section). Might be good to address the arguments shown there…
4 Likes
Thanks, missed that in PEP.
Well, author’s view is mostly in line with mine.
Essentially, it is good to implement basic functionality first and leave extensions for later if anybody needs it. Other stated issues do not seem like issues, but rather minor considerations.
And in this case things are very straight forward.
Just to clear it out - I am not pushing this. If people agree that this is useful, then it could be a nice little project for someone who is keen.