And we *have* to decide that it returns a plain str instance if called on a subclass instance (unless overridden, of course) since the base class (str) won't know the signature of the subclass constructor. That's also why all other str methods return an instance of plain str when called on a subclass instance.

My suggestion is to rely on __getitem__ here (for subclasses), in which case we don't actually need to know the subclass constructor. The rough implementation in the PEP shows how to do it without needing to know the subclass constructor:

def redbikeshed(self, prefix):
    if self.startswith(pre):
        return self[len(pre):]
    return self[:]

The actual implementation doesn't need to be implemented that way, as long as the result is always there result of slicing the original string, it's safe to do so* and more convenient for subclass implementers (who now only have to implement __getitem__ to get the affix-trimming functions for free).

One downside to this scheme is that I think it makes getting the type hinting right more complicated, since the return type of these functions is basically, "Whatever the return type of self.__getitem__ is", but I don't think anyone will complain if you write -> str with the understanding that __getitem__ should return a str or a subtype thereof.

Best,
Paul

*Assuming they haven't messed with __getitem__ to do something non-standard, but if they've done that I think they've tossed Liskov substitution out the window and will have to re-implement these methods if they want them to work.

On 3/22/20 2:03 PM, Guido van Rossum wrote:
On Sun, Mar 22, 2020 at 4:20 AM Eric V. Smith <eric@trueblade.com> wrote:
Agreed. I think the PEP should say that a str will be returned (in the
event of a subclass, assuming that's what we decide), but if the
argument is exactly a str, that it may or may not return the original
object.

Yes. Returning self if the class is exactly str is *just* an optimization -- it must not be mandated nor ruled out.

--
--Guido van Rossum (python.org/~guido)

_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/ZZTY3OCJFZTZM74MVWRYL23LFJGNKICU/
Code of Conduct: http://python.org/psf/codeofconduct/