Brendan Barnwell writes: > What it means for me for something to "be an HTML string" (or more > precisely, to be an instance of HTMLString or whatever the class name > is) is for it to be a string that has an extra tag attached to the > object that means "this is HTML".
I don't like tags that lie. Seems pointless (see below). > The point is that overrides are for specifying the *new* behavior > of the subclass (i.e., not allowing certain slice operations); you > shouldn't have to override methods just to retain the superclass > behavior. Do you mean "retain the subclass behavior" here? AFAICS what's being called "hostile" is precisely retaining *superclass* behavior. > I mean, we were talking about this in the context of syntax > highlighting. The utility of HTML-string highlighting would be > seriously reduced if only *valid* HTML could be in an HTML string. The proposed HTMLstring *class* is irrelevant to syntax highlighting, regardless of its functionality. The OP (and his syntax-highlighting text editor!) wants standard literal syntax *in source code* that allows an editor-that-is-not-as-programmable-as-emacs-or-vim to recognize a fragment of text (typically in a literal string) that is supposed to be highlighted as HTML. Syntax highlighting is not aided by an HTMLstring object in the *running Python program*. I really don't understand what value your HTMLstring as str + tag provides to the OP, or to a Python program. I guess that an editor written in Python could manipulate a list of TaggedString objects, but this is a pretty impoverished model. Emacsen have had extents/ overlays since 1990 or so, which can be nested or overlap, and nesting and overlapping are both needed for source code highlighing.[1][2] I don't take a position on the "builtins are hostile to subclassing" debate. I can't recall ever noticing the problem, so I'll let you all handle that. :-) Footnotes: [1] In Emacsen, tagged source text (overlays) is used not only for syntax highlighting which presumably is nested (but TagSoup HTML!), but also to implement things like hiding text, which is an operation on raw text that need not respect any syntax. [2] XEmacs's implementation of syntax highlighting actually works in terms of "extent fragments" which are non-overlapping, but they're horrible to work with from a editor API standpoint. They're used only in the implementation of the GUI display, for performance reasons, and each one typically contains a plethora of tags. _______________________________________________ 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/UVQ6PGUKF5EG6UZWOBI76ZQANNFVC5TS/ Code of Conduct: http://python.org/psf/codeofconduct/
