On 2022-12-19 13:59, Chris Angelico wrote:
On Tue, 20 Dec 2022 at 07:13, Brendan Barnwell <brenb...@brenbarn.net> wrote:
> 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.
The enum module was added in Python 3.4.
Your example used StrEnum, which was added in Python 3.11.
Nonetheless, a StrEnum is absolutely a str, and whatever you say about
an HTML string has to also be valid for a StrEnum, or else the inverse
is.
No, it doesn't, because HTMLString and StrEnum can be different
subclasses of str with different behavior. You seem to be missing the
concept of subclasses here. Yes, a StrEnum may be an instance of str,
and an HTMLString may also be an instance of str. But that does not
mean the behavior of both needs to be same. They are instances of
*different subclasses* of str and can have *different behavior*. An
instance of collections.Counter is an instance of dict and so is an
instance of collections.defaultdict, but that doesn't mean that anything
I say about a Counter has to be valid for a defaultdict.
One way that some libraries implement this for their own classes is to
have an attribute or method called something like `_class` or
`_constructor` that specifies which class to use to construct a new
instance when needed. By default such a class may return an instance of
the same type as self (i.e., the most specific subclass), but subclasses
could override it to do something else.
The way things are, a StrEnum or an HTML string will behave *exactly
as a string does*. The alternative is that, if any new operations are
added to strings in the future, they have to be explicitly blocked by
StrEnum or else they will randomly and mysteriously misbehave - or, at
very best, crash with unexpected errors. Which one is more hostile to
subclasses?
I already answered that in my previous post. To repeat: StrEnum is the
unusual case and I am fine with it being more difficult to create
something like StrEnum, because that is not as important as making it
easy to create classes that *do* return an instance of themselves (i.e.,
an instance of the same type as "self") from their various methods. The
current behavior is more hostile to subclasses because people typically
write subclasses to *extend* the behavior of superclasses, and that is
hindered if you have to override every superclass method just to make it
do the same thing but return the result wrapped in the new subclass.
--
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/TYEXVQ3YLPTUM6LOF2657OXGDD5DNHPZ/
Code of Conduct: http://python.org/psf/codeofconduct/
