> I imagine it's an implementation detail of which ones depend on
> ``__getitem__``.
If we write
class MyStr(str):
def __getitem__(self, key):
raise ZeroDivisionError()
then all of the assertions from before still pass, so in fact *none* of
the methods rely on ``__getitem__``. As of now ``str`` does not behave
as an ABC at all.
But it's an interesting proposal to essentially make it an ABC. Although
it makes me curious what all of the different reasons people actually have
for subclassing ``str``. All of the examples I found in the stdlib were
either (1) contrived test cases (2) strings (e.g. grammar tokens) with
some extra attributes along for the ride, or (3) string-based enums.
None of types (2) or (3) ever overrode ``__getitem__``, so it doesn't
feel like that common of a use case.
> I don't see removeprefix and removesuffix explicitly being implemented
> in terms of slicing operations as a huge win - you've demonstrated that
> someone who wants a persistent string subclass still would need to
> override a /lot/ of methods, so two more shouldn't hurt much - I just
> think that "consistent with most of the other methods" is a
> /particularly/ good reason to avoid explicitly defining these operations
> in terms of __getitem__.
Making sure I understand: would you prefer the PEP to say ``return self``
rather than ``return self[:]``? I never had the intention of ``self[:]``
meaning "this must have exactly the behavior of
``self.__getitem__(slice(None, None))`` regardless of type", but I can
understand if that's how you're saying it could be interpreted.
_______________________________________________
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/A64Q6BXTXJYNTA4NX2GHBMOG6FPZUCZP/
Code of Conduct: http://python.org/psf/codeofconduct/
