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