On Wed, 21 Dec 2022 at 09:30, Cameron Simpson <c...@cskk.id.au> wrote: > > On 19Dec2022 22:45, Chris Angelico <ros...@gmail.com> wrote: > >On Mon, 19 Dec 2022 at 22:37, Steven D'Aprano <st...@pearwood.info> wrote: > >> > But this much (say with a better validator) gets you static type > >> > checking, > >> > syntax highlighting, and inherent documentation of intent. > >> > >> Any half-way decent static type-checker will immediately fail as soon as > >> you call a method on this html string, because it will know that the > >> method returns a vanilla string, not a html string. > > > >But what does it even mean to uppercase an HTML string? Unless you > >define that operation specifically, the most logical meaning is > >"convert it into a plain string, and uppercase that". > > Yes, this was my thought. I've got a few subclasses of builtin types. > They are not painless. > > For HTML "uppercase" is a kind of ok notion because the tags are case > insensitive.
Tag names are, but their attributes might not be, so even that might not be safe. > Notthe case with, say, XML - my personal nagging example is > from KML (Google map markup dialect) where IIRC a "ScreenOverlay" and a > "screenoverlay" both existing with different semantics. Ugh. Ugh indeed. Why? Why? Why? > So indeed, I'd probably _want_ .upper to return a plain string and have > special methods to do more targetted things as appropriate. > Agreed. ChrisA _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/T7FZ3FIA6INMHQIRVZ3ZZJC6UAQQCFOI/ Code of Conduct: http://python.org/psf/codeofconduct/
