Dennis Sweeney wrote:
Steven D'Aprano wrote:
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.
The Python interpreter in my head sees `self[:]` and returns a copy. A
note that says a `str` is returned would be more useful than trying to
exactly mirror internal details in the Python "roughly equivalent" code.
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.
I agree with Steven -- a tuple of options is not necessary for the affix removal
methods.
--
~Ethan~
_______________________________________________
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/EDWFPEGQBPTQTVZV5NDRC2DLSKCXVJPZ/
Code of Conduct: http://python.org/psf/codeofconduct/
