On Wed, Dec 21, 2022 at 09:42:51AM +1100, Cameron Simpson wrote:
> With str subtypes, the case that comes to my mind is mixing str
> subtypes.
[...]
> So, yes, for many methods I might reasonably expect a new html(str). But
> I can contrive situations where I'd want a plain str
The key word there is *contrive*.
Obviously there are methods that are expected to return plain old
strings. If you have a html.extract_content() method which extracts the
body of the html document as plain text, stripping out all markup, there
is no point returning a html object and a str will do. But most methods
will need to keep the markup, and so they will need to return a html
object.
HTML is probably not the greatest example for this issue, because I
expect that a full-blown HTML string subclass would probably have to
override nearly all methods, so in this *specific* case the status quo
is probably fine in practice. The status quo mostly hurts *lightweight*
subclasses:
class TurkishString(str):
def upper(self):
return TurkishString(str.upper(self.replace('i', 'İ')))
def lower(self):
return TurkishString(str.lower(self.replace('I', 'ı')))
That's fine so long as the *only* operations you do to a TurkishString
is upper or lower. As soon as you do concatenation, substring
replacement, stripping, joining, etc you get a regular string.
So we've gone from a lightweight subclass that needs to override two
methods, to a heavyweight subclass that needs to override 30+ methods.
This is probably why we don't rely on subclassing that much. Easier to
just write a top-level function and forget about subclassing.
--
Steve
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/Q6JQVEUAQXGX6EMAFVGYGGF7ZENUSMRP/
Code of Conduct: http://python.org/psf/codeofconduct/
