First off, thank you for being so patient -- trying to champion a PEP can be exhausting. On 03/26/2020 05:22 PM, Dennis Sweeney wrote:
Ethan Furman wrote:
I don't understand that list bit -- surely, if I'm bothering to implement removeprefix and removesuffix in my subclass, I would also want to return self to keep my subclass? Why would I want to go through the extra overhead of either calling my own __getitem__ method, or have the str.__getitem__ method discard my subclass?
I should clarify: by "when working with subclasses" I meant "when str.removeprefix() is called on a subclass that does not override removeprefix", and in that case it should return a base str.
Okay.
However, if you are saying that self[:] will call self.__class__.__getitem__ so my subclass only has to override __getitem__ instead of removeprefix and removesuffix, that I can be happy with.
I was only saying that the new methods should match 20 other methods in the str API by always returning a base str
Okay.
If ``return self[:]`` in the PEP is too closely linked to "must call user-supplied ``__getitem__`` methods" for it not to be true, and so you're suggesting ``return self`` is more faithful, I can understand.
So now if I understand the dilemma up to this point we have:
Benefits of writing ``return self`` in the PEP: a - Makes it clear that the optimization of not copying is allowed b - Makes it clear that ``self.__class__.__getitem__`` isn't used
Benefits of writing ``return self[:]`` in the PEP: c - Makes it clear that returning self is an implementation detail d - For subclasses not overriding ``__getitem__`` (the majority of cases), makes it clear that this method will return a base str like the other str methods.
Did I miss anything?
The only thing you missed is that, for me at least, points A, C, and D are not at all clear from the example code. If I wanted to be explicit about the return type being `str` I would write: return str(self) # subclasses are coerced to str -- ~Ethan~