On Tue, Jun 4, 2019 at 2:50 PM Eric V. Smith <eric@trueblade.com> wrote:
On 6/4/2019 8:38 AM, Steven D'Aprano wrote:
On Tue, Jun 04, 2019 at 01:20:14PM +0100, Rhodri James wrote:
On 04/06/2019 11:06, Yanghao Hua wrote:
[...] what I needed is an operator that does not collide with all existing number/matrix operators.
Why?
That's the question that in all your thousands of words of argument you still haven't answered beyond "because I want it."
(1) Because they're already being used. That rules out operators that are supported by numbers at least, since the primitive values in his code are numbers.
So once you remove the operators supported by numbers:
+ - * / // & ** ^ & | << >> ~ < > <= >= == !=
(have I missed any?) I think that only leaves @ remaining.
One problem is that this has no end. Say <== is added (for "signals"), then someone will say "I want something just like a signal, but with this one additional operator". What then?
As sad as it may be to many people (and I'm one of them), Python just isn't the right fit for designing DSLs. And if we want to improve it in that area, SQL is the first place we should start looking. SQLAlchemy has any number of functions or weird use of operators (.in_(), &&, etc.) that could be improved. SQLAlchemy chose to just accept that Python is what it is, and did they best they could, even though some of the constructs are not ideal. And I think it's been pretty successful.
As though as it is an objection I do like the reasoning a lot more, and that's exactly why the title for this thread I was choosing is " ... yet another operator?". And Yes SQLAlchemy shows similar scenarios where Python is not yet good at. And I know the potential huge challenge to actually change something fundamentally ... but sometimes hope is the most important thing: is Python visioned in a way to allow users to define there own operators? I think this will be a huge topic in the coming future. In a world where people just do general purpose programming/computing, to a world that every one can design its own system-on-chip, there will simply be more and more domain-specific languages. This is where I see scala picks up more and more. And as a Python fan, I really do hope Python could support this (just like it picked up async/await from C#) and make it truly the first-choice for designing a domain specific language.