On Fri, May 24, 2019 at 10:30 AM Paul Moore <p.f.mo...@gmail.com> wrote: > 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 am struggling with this myself as well ... but Python is arguably one of the best language to represent ideas. When I wrote "if python is going to support scala like operator constructions" I meant more to ask "If someone out there already had this plan and working on it", rather than advocating it myself too strong (I would really love it though, but not the part that calls a function without parentheses). > 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. Python is great! I am in no way saying anything bad about python only because it is missing one feature. But I do think it can still be better and better. I guess in the past there is just not enough interests from hardware people to use Python to design hardware. We had MyHDL, cocotb, etc. as well as my own Python-Verilog co-simulator ... because SystemVerilog really makes me sick ... for a language that has more than 250+ reserved keywords you can imagine it is even worse than C++ and no two vendor could ever build a compiler for system verilog behaves exactly the same (I don't even know if the spec itself can be self-consistent ... just too many possibilities to go wrong) ... that's why I build the Python-Verilog co-simulator where I can write much more powerful testbenches just in a few lines of Python. > 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. Sure and will work on it. I am not sure if the argument can come as strong as in PEP 465, as numpy community (which has almost the entire machine-learning world) is considerably larger than python hardware design community ... but I will try to see if I can convince some of you guys. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
