Steven D'Aprano wrote: > On Tue, Mar 24, 2020 at 08:14:33PM -0000, Dennis Sweeney wrote: > > I think then maybe it would be preferred to > > use the something like the following in the PEP: > > def cutprefix(self, prefix, /): > > if isinstance(prefix, str): > > if self.startswith(prefix): > > return self[len(prefix):] > > return self[:] > > > > Didn't we have a discussion about not mandating a copy when nothing > changes? For strings, I'd just return self. It is only bytearray that > requires a copy to be made.
It appears that in CPython, ``self[:] is self`` is true for base ``str`` objects, so I think ``return self[:]`` is consistent with (1) the premise that returning self is an implementation detail that is neither mandated nor forbidden, and (2) the premise that the methods should return base ``str`` objects even when called on ``str`` subclasses. > > elif isinstance(prefix, tuple): > > for option in prefix: > > if self.startswith(option): > > return self[len(option):] > > > > I'd also remove the entire multiple substrings feature, for reasons I've > already given. "Compatibility with startswith" is not a good reason to > add this feature and you haven't established any good use-cases for it. > A closer analog is str.replace(substring, ''), and after almost 30 years > of real-world experience, that method still only takes a single > substring, not a tuple. The ``test_concurrent_futures.py`` example seemed to be a good use case to me. I agree that it would be good to see how common that actually is though. But it seems to me that any alternative behavior, e.g. repeated removal, could be implemented by a user on top of the remove-only-the-first-found behavior or by fluently chaining multiple method calls. Maybe you're right that it's too complex, but I think it's at least worth discussing. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/TRTHGTLOEQXSYYXKQ6RFEXMGDI7O57EL/ Code of Conduct: http://python.org/psf/codeofconduct/
