Thanks for the review!
> In short, I propose:
> def cutprefix(self: str, prefix: str, /) -> str:
> if self.startswith(prefix) and prefix:
> return self[len(prefix):]
> else:
> return self
>
> I call startswith() before testing if pre is non-empty to inherit of
> startswith() input type validation. For example, "a".startswith(b'x')
> raises a TypeError.
This still erroneously accepts tuples and and would return return str
subclasses unchanged. If we want to make the Python be the spec with accuracy
about type-checking, then perhaps we want:
def cutprefix(self: str, prefix: str, /) -> str:
if not isinstance(prefix, str):
raise TypeError(f'cutprefix() argument must be str, '
f'not {type(prefix).__qualname__}')
self = str(self)
prefix = str(prefix)
if self.startswith(prefix):
return self[len(prefix):]
else:
return self
I like the idea to always require these to return the unmodified string. Is
there a reason this isn't specified by the ``replace()`` or ``strip`` methods?
For accepting multiple prefixes, I can't tell if there's a consensus about
whether ``s = s.cutprefix("a", "b", "c")``
should be the same as
for prefix in ["a", "b", "c"]:
s = s.cutprefix(prefix)
or
for prefix in ["a", "b", "c"]:
if s.startwith(prefix):
s = s.cutprefix(prefix)
break
The latter seems to be harder for users to implement through other means, and
it's the behavior that test_concurrent_futures.py has implemented now, so maybe
that's what we want. Also, it seems more elegant to me to accept variadic
arguments, rather than a single tuple of arguments. Is it worth it to match the
related-but-not-the-same API of "startswith" if it makes for uglier Python? My
gut reaction is to prefer the varargs, but maybe someone has a different
perspective.
I can submit a revision to the PEP with some changes tomorrow.
_______________________________________________
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/GXGP5T5KC6ZEBZ5AON4G3MHIKO6MAU35/
Code of Conduct: http://python.org/psf/codeofconduct/