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

[Chris Angelico]

On Mon, May 27, 2019 at 5:25 AM Yanghao Hua <yanghao.py at gmail.com> wrote:
>
> 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.

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.

ChrisA