On Fri, 24 May 2019 at 09:06, Yanghao Hua firstname.lastname@example.org wrote:
Well, if python is not envisioned to be able to represent almost everything elegantly maybe I should indeed walk away from this idea. (This is sad for me ... I have been saying and believing python is envisioned that way for more than 20 years now).
Personally, my understanding is that Python is not designed to make writing DSLs in Python easy (I'm a little sad about this fact myself, but I accept that trying to make a language good at everything is counter-productive). Features like the ability to call functions without parentheses, user-defined operators, user-defined syntax in general, are directly intended to make writing DSLs easier, and have been requested and rejected many times in the past.
I believe Python is OK (I may even go as far as saying "pretty good") for defining simple DSLs, but it's not a core goal of the language, and you have to make your DSL fit with Python's syntax, not the other way round.
That's not to say that features useful for DSLs aren't ever going to be accepted, but they will need justification independent of their value in DSLs. The matrix @ operator that you quote wasn't accepted because "it reads well in a maths context", the proponents did a lot of research to demonstrate that the operator simplified existing code, and existing language features couldn't deliver the benefits. PEP 465 is well worth a read to give an idea of the sorts of arguments needed to successfully introduce a new operator to Python.