> You do realise that repeatedly avoiding the question "what problem do > you think you are solving?" does not convincingly make the case that > there is a problem to be solved, don't you?
It might be that I am not good enough yet to present it in a way for some of you to better comprehend it. But I do see positive feedbacks too. I plan to stop this discussion here and make a toe-to-toe comparison how it looks like without assignment overloading, how it looks like with assignment overloading, and how it compares with other languages like verilog and Scala/Chisel, and in the meantime to look into some corner cases to make sure the proposed solution can cover all situations. To repeat what the problem do I think I am solving? A variable, that behaves like an integer (e.g. all normal integer ops should just work), but has a different assignment behavior, such that it can be used to develop equally good hardware descriptions. And why bother using Python to design hardware? Because the problem of hardware is not the design of hardware itself, 60% to 80% of the effort is on verification. Many python verification framework exists (cocotb, myhdl, and my own) which has proven to be very useful when verifying hardware. If the last mile which is to describe hardware directly in python (has to be equally good and intuitive and char-conservative as in verilog or chisel), then I can throw away thousands of lines of interfacing code that bridges verilog and python, and has a long term possibility to optimize its speed by using pypy. No decorators for end user, no forced coroutines for end user, almost native *simple* python syntax, is the only possible way I see to attract real hardware developers (like Chisel). _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
