On Sun, May 26, 2019 at 7:11 PM Barry Scott <ba...@barrys-emacs.org> wrote: > You said this: "Well, depends on how we define narrow ... you are writing > probably > this email on a HDL designed machine ... and the entire world is > powered by HDL designed silicons. that is not small for me at all." > > Which I take to mean that because there are billions of chips in the world > there are > billions of python users. And the change you want is justified by the > billions of python users.
No offense but it is a bit too optimistic too think there are billions of python users (who actually write python code). And it is a bit too pessimistic to think there are billions of chips in the world ... the chips I personally worked on most likely exceeded the billion mark. So put this in perspective there are hundreds of billions of chips being produced, this is the problem space of *secondary* impact. the *primary* impact could be a few million (my estimation) HDL developers, and a dozen million HDL verification engineers. It is definitely smaller than the entire python developer community because probably all of the hardware/silicon engineers write a few lines of python. I just want to say this is *NOT* a small problem at all. SiFive can now develop RISC-V CPUs which is faster and more efficient than the respective ARM versions is probably the best testimony that a better HDL matters. > There is a reason that there are 1,000s of computer languages in the world. > Not all computer languages are able to solve all problems. > > If Chisel or Scala is closer to what you want why are you not using them for > your HDL tools? Yes of course ... and python keeps solving more of them with PEPs ... and the whole motivation for me to discuss here is I think Python is so close to solve the HDL problem too (give me a way to override assignment and do not mess up the existing operators which I do love and want to mix with the overloaded assignment operators). Chisel does not solve all the problems (yet), and I have never been a scala developer, so I do want to give a push in Python before I decide to switch to scala/chisel. > What has that got to do with justifying a change to the python language? I think every language has to has a vision, and I thought Python's vision is to use less chars to present bigger ideas, and logically I thought assignment overloading but not messing up existing operators could have been resonating in python community. > And it seems that you have hit a major problem with the HDL syntax not > mapping to python. > Maybe python is not the right choice? This is actually the only problem I hit ... python seems to be the right choice in all the rest 99% cases I have ever met. > > For any non-trivia hardware I'm finding it hard to believe that python will > run fast enough to be useful. > What is it that I'm missing? > > > We are all Python users and we start to worry about running fast? > really? ;-) I thought we all understood development time matters (if > not even more ...) > > > Packages like numpy are not written in python for a reason. A pure > python numpy would be very slow. So yes we worry about run time speed. numpy is not Python! numpy is C! Python does not have numpy! I am a bit surprised that we python community is even denying python is slow? You bench mark it in all possible ways python is still slow, if not the slowest. That's a known fact and we always do python prototyping and optimize the critical path/parts into C. Python is not build for speed. (don't bring in pypy for now please ... ) What we love about python is its development speed. The same applies to the world of hardware design and verification. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
