On Tue, Jun 4, 2019 at 2:50 PM Eric V. Smith <e...@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. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
