Hi Victor. I accidentally created a new thread, but I intended everything below
as a response:
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
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 soon.
_______________________________________________
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/NYVDSQ7XB3KOXREY5FUALEILB2UCUVD3/
Code of Conduct: http://python.org/psf/codeofconduct/
