On Fri, May 24, 2019 at 11:47 AM Steven D'Aprano <st...@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. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/