On Sat, Jun 15, 2019 at 10:26 PM Guido van Rossum <gu...@python.org> wrote:
> I don't actually know how viable this proposal is, but given that it's being
> debated at some length, I'd like to put in my opinion that *if* we're going
> to define an operator that's (roughly) synonymous with issubclass(), it
> should be '<:', which is used in other languages (e.g. Scala) and notational
> systems (https://en.wikipedia.org/wiki/Subtyping). Overloading '<=' would be
> easier to implement, but would also cause enough confusion that I think we
> should avoid it at all cost.
Note that making new operators means class containment relationships
can't be used as normal comparisons, such as for `sort`, especially of
nested comparables such as tuples of classes. I'm not sure how to
define a sort key that works even for a simple list of classes, other
than to create a wrapper which implements class comparisons.
I don't think the proposal is viable. It might have been viable if one
of these conditions were true:
1. A lot more programmers learned, from the start, to think of types
as collections of their instances. Then the consistency would pay off,
by reducing mental load for those programmers.
2. There were more libraries/features that used comparison operators
AND there was a reason for classes to ducktype into those libraries.
3. Subclass checking often happened within complex boolean algebra.
The succinctness of operators would then help readability.
For simple boolean algebra, issubclass and isinstance can take tuples
of classes:
issubclass(C, (A, B)) # Checks if C is a subclass of A OR B.
_______________________________________________
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/HYEKHUCJFS3UW7HBQ7UTDNPLTIAPF7PD/
Code of Conduct: http://python.org/psf/codeofconduct/
