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

[Yanghao Hua]

On Fri, May 24, 2019 at 11:47 AM Steven D'Aprano <steve at pearwood.info> wrote:

> PEP 465 had a concrete purpose for its new operator, and although no
> built-in object supported the @ operator, we understood why Numpy wanted
> it. But I do not understand why you want an arrow operator or what you
> will do with it.

OK, I see your point and will work on a more comprehensive example
with some investigations how it can simplify existing libraries
outside there.

> What should built-in types do with this new dunder?
>
>     "Hello world!" <== "aardvark"
>
>     23.5 <== 1.25
>
>     [1, 2, 3] <== 4

It will generate error: unsupported operand types(s) for: 'int' and
'int'. (or list and int etc.)

>
> Have you considered the __ilshift__ method?
>
>     signal <<= 5

I explained already but here again: you will need to have "this_signal
<<= (that_signal << 4) + something, and next line you should be able
to write this_signal <<= 4 bit, where all arithmetic operation still
have to be kept. Otherwise it makes signal doesn't look like a value
... it needs to be looking like a integer but with a different
assignment behavior. In hardware design domain a signal is just a
value but with its own assignment behavior involving delta-cycles (a
virtual time step increase of the value zero ... I know it is a bit
confusing to SW developers). So the intention is to keep all
arithmetic ops like a int, but only changing how the assignment is
done.

> Yes. You should study PEP 465. It is one of the best PEPs in Python's
> history. If you want your proposal to succeed, you should think "How can
> I write this to be more like PEP 465?"

I am writing just to see if I missed something significantly in this
field ... will come back with a comprehensive PEP.

> I am completely aware that we can't hook into assignment except with
> attribute or item assignment. But I still do not understand why you want
> to hook into assignment.

What is going to be hooked into the assignment is the pending update
of the value to the signal, which only happens until a delta cycle is
passed, such that you can have a deterministic behavior when using
software to mimic actual hardware behaviors.

> Perhaps I have missed something when reading your earlier posts, but I
> don't understand what you will do with this new operator. Perhaps you
> can show up your intended method?
>
>
> x <== y
>
> def __arrow__(self, other):
>    # what goes here?

For example:

def __larrow__(self, other):
    self.next_value = other.value

And when increasing virtual time (e.g. a delta cycle):

for sig in all_signals:
    sig.current_value = self.next_value


> I am not sure if I understand what you mean by "feeding 5 into this
> signal". But if it means what I think it means, then you can give signal
> a method:
>
>     signal.feed(5)
>
> which is explicit and readable. Or you could use <<= as I mentioned
> above.

The intention is to make the signal looks like an integer, and yet to
change the assignment behavior. As I explained above that all normal
arithmetic ops still need to be kept.

> You also said:
>
>     "[arrow operator] looks like kind of the non-blocking
>     assignment operators in hardware description languages"
>
> What is "non-blocking assignment"?

non-blocking assignment is a terminology in HDL design, where the
assignment is not actually happening until a later time. In simple
words if the "virtual-time" is not increasing, then the assignment is
not happening. To allow all hardware threads seeing the same
consistent value at that particular virtual time.

I have the prototype working, let me implement a much more elaborated
example, and also look into how existing modules like MyHDL could
benefit out of it, and give you guys a written PEP.

>From this good discussion so far (Thanks everyone for your candid
responses!), I understood I have not missed anything significantly,
Python community has no intention to make Python supporting
operator-on-demand-definition like in scala, so the only possible way
forward is (for me): build the "<== and ==>" operator and write a PEP
to justify its usefulness. The general intention is to make HDL design
in python looks and feels at least as good as in verilog/vhdl, so once
I have my library complete I will explain in depth how it looks side
by side for Python vs Verilog, with and without the arrow operators.