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~
_______________________________________________
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/XWVJNFN5O3BZQ6YQQEWHMOGRWST3MY6M/
Code of Conduct: http://python.org/psf/codeofconduct/
