On 20Dec2022 20:16, Steven D'Aprano <steve@pearwood.info> wrote:
On Mon, Dec 19, 2022 at 05:53:38PM -0800, Ethan Furman wrote:
Personally, every other time I've wanted to subclass a built-in data type, I've wanted the built-in methods to return my subclass, not the original class.
Enums are special. But outside of enums, I cannot think of any useful situation where the desirable behaviour is for methods on a subclass to generally return a superclass rather than the type of self.
With str subtypes, the case that comes to my mind is mixing str subtypes. I happen to be wallowing in Django admin forms at the moment, and they have a mark_safe(some_html_here) function, which seems to return a str subtype (I infer - it's what I would be doing) - this is used in the templating engine to know that it _doesn't_ need to escape markup punctuation at render time. The default is escaping, to avoid accidental injection. So... I'd want an "html" str to support, say, addition to construct longer strings. html(str)+str should make a new html str with the plain str escaped. html(str)+css(str) should raise a TypeError. Etc etc. html(str).upper() might uppercase only the bits outside the tags i.e. "<b>foo</b>" -> "<b>FOO</b>". 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, and I'd be leery of "every method returns html(str)" by default - because such a string has substructure that seems to warrant careful thought. Cheers, Cameron Simpson <cs@cskk.id.au>