On Mon, May 27, 2019 at 5:25 AM Yanghao Hua email@example.com wrote: >
On Sun, May 26, 2019 at 7:11 PM Barry Scott firstname.lastname@example.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.
Irrelevant though. I've ridden in a car - does that make me a petrochemical engineer?
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!
(Fortran, for what it's worth)
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.
Actually, I just code in Python. And when I ask if a dictionary contains a particular key, I don't care that this is implemented in C; all I care about is whether the dictionary contains that key. Am I writing C code? Nope. I'm writing Python code.
And PyPy is actually quite relevant, because it runs normal Python code. You don't have to "optimize ... into C". You just write Python, and then run it using a Python interpreter.
This discussion may need to move to python-list rather than -ideas, as this isn't really progressing towards any sort of language improvement.