On Fri, May 24, 2019 at 11:47 AM Steven D'Aprano email@example.com 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?
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:
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.