On Tue, Jun 18, 2019 at 5:01 AM Emin Bugra Saral via Python-ideas <python-ideas@python.org> wrote:
`<:` kind of notation would look more clear, I agree.
My proposition came after thinking the wording used in Python.
issubclass() - is subclass?
By definition, subclass reminds me set theory. https://en.wikipedia.org/wiki/Subclass_(set_theory) which also has a relativity with Subtyping as Guido pointed out.
And, we have operator support for set() as you can see here https://docs.python.org/3/library/stdtypes.html#set `set <= other`
With this logic, since Python has its own way of being practical and predictable in some ways, I would except to have an operator like `<:`, which some other languages already possess.
A <: B against issubclass(A, B) looks more elegant, and purpose driven syntax like most of other types.
I see that there is also `issubset` method which is equivalent to `set <= other`. Therefore I find this a little bit inconsistent that we don't apply the similar logic for issubclass.
Adding a new operator means more to learn for people reading code. It's difficult to search for operators, especially when you're new to Python. The @ operator is less bad, in that it's (usually) specific to Numpy code, and it will be ubiquitous enough among Numpy users that they'll pick it up along the way (either in a tutorial or otherwise). Even if it were more bad, matrix multiplication is usually in complex-enough expressions that the new operator helps readability, and the costs are outweighed by the benefits. There is also a domain advantage, because the people reading and writing the expressions are used to expressing those lines using mathematical symbols. For example, A @ A.T @ v + B @ B.T @ v is better than A.dot(A.T).dot(v).__add__(B.dot(B.T).dot(v)) and it's easier to see that you can refactor the first as (A @ A.T + B @ B.T) @ v than the second. On the other hand, type comparison is NOT often used in the middle of complex expressions, because the result of a type comparison is bool, and you don't often do much arithmetic with bools. There isn't much chaining or nesting. The people reading and writing type expressions are general programmers, NOT mathematicians or scientists. For example, if (A <: B or A <: C) and A <: D: is not much better than if issubclass(A, (B, C)) and issubclass(A, D): especially if you don't know what either of those mean. You can search for issubclass, but you can't search for <:. To show that you really do need the feature, you need to show the complex expressions you write with issubclass that would be improved by using an operator.
I don't know if we could achieve same performance of issubclass itself with the operator (I think we can) but even it's not the case, people who uses Python to write their scripts very fast, that would be a lovely addition.
I believe the performance cost will be negligible. A function call requires a lookup and a call. An operator requires one or more lookups and a call. However, the bigger cost will be in grabbing the MRO, iterating through it, and checking for virtual subclassing. You're also not going to be doing type comparisons in a huge loop.