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.
_______________________________________________
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/3ZOPALWYFEY65QUMEEJPWBK3KLY6TCMG/
Code of Conduct: http://python.org/psf/codeofconduct/
