[Python-ideas] Operator as first class citizens -- like in scala -- or yet another new operator?

[Yanghao Hua]

On Sun, May 26, 2019 at 7:11 PM Barry Scott <barry at 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.