If we want to avoid new operators, I think that the existing “from” keyword is
also a good candidate:
if A from (B, C) and A from D:
...
I’m still skeptical of the value of this feature, though.
Brandt
> On Jun 19, 2019, at 08:56, Franklin? Lee <[email protected]>
> wrote:
>
> On Tue, Jun 18, 2019 at 5:01 AM Emin Bugra Saral via Python-ideas
> <[email protected]> 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 -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/3ZOPALWYFEY65QUMEEJPWBK3KLY6TCMG/
> Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/XGAYBS63ZBDQ2X7SZG5SQVW2IMDH265I/
Code of Conduct: http://python.org/psf/codeofconduct/
