Sorry, accidentally replied off-list. . .
On 2022-12-19 11:36, Chris Angelico wrote:
On Tue, 20 Dec 2022 at 06:29, Brendan Barnwell <brenb...@brenbarn.net> wrote:
On 2022-12-19 03:45, Chris Angelico 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". Or, similarly,
slicing an HTML string. You could give that a completely different
meaning (maybe defining its children to be tags, and slicing is taking
a selection of those), but if you don't, slicing isn't really a
meaningful operation.
I don't agree with that at all. What it means for an HTML string to be
a subclass of a normal string is that all normal string operations still
work on an HTML string --- just like what it means for any instance of a
subclass to be an instance of the superclass is that you can do anything
to the subclass that you could do to the superclass. Every character in
an HTML string is still a character and can still be uppercased. The
string is still a sequence of characters and can be sliced. All such
operations still have a perfectly natural meaning.
And that part is already true. None of this changes. That's guaranteed
by the concept of subclassing. But what you're doing is string
operations on a string.
We just want them to
now return an *HTML* string when they're done instead of a normal one.
The point of having a subclass is to define *additional* behavior while
still retaining the superclass behavior as well.
So how is it still an "HTML" string if you slice out parts of it and
it isn't valid HTML any more?
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". That's it. You can make an HTML
string that contains utter gobbledegook if you want. Of course, some
operations may fail (like if it has a .validate() method) but that
doesn't mean it's not still an instance of that class.
Or, if you do want that, you can override the slicing method to raise
an error if the result isn't valid HTML. 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.
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.
>> Personally I find Python's behavior in this regard (not
just for
>> strings but for other builtin types) to be one of its most irritating
>> warts.
>
> See my example regarding a StrEnum and tell me whether that would be
> more irritating.
I can't run that example myself as I don't have Python 3.11 set up.
But just from what you showed, I don't find it convincing. Enums are
special in that they are specifically designed to allow only a fixed set
of values. I see that as the uncommon case, rather than the common one
of subclassing an "open-ended" class to create a new "open-ended" class
(i.e., one that does not pre-specify exactly which values are allowed).
So no, I don't think it would be more irritating.
--
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is no
path, and leave a trail."
--author unknown
_______________________________________________
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/CT7UM6REJZEA3L6HHI2CGHMPXRZ7NXHI/
Code of Conduct: http://python.org/psf/codeofconduct/
