Steven D'Aprano writes: > You might be right, but then the first post in this thread talked > about it: > > I realize there is no way to overload the behavior of the > assignment operator in python > > ... where signal = 5 will always make signal to be 5, instead of > feeding 5 into this signal.
I've seen no hint that "signal arithmetic" is a thing, so as far as I can see Chris Angelico's "+=" (analogous to "feeding characters into the end of a string") wins. (The OP simply ignored the argument, and replied "but I want '<==='".) Or you can make the algebraists happy with "*=". If you need "+=" for signal addition in an arithmetical sense, maybe "*=" is still available at the sacrifice of the possibility of saying "signal *= 5" to mean "repeat last signal 5 times", and some degree of "WTF multiplication? oh yeah ...". signal = Signal() signal = Signal(args) # args might preload stuff into a buffer # or configure the Signal in some way signal += value # signal changes state to value, read # "signal gets next <value>". Unless Yanghao can come up with a reason not to use this such as (a) he needs that operator for a more natural meaning, or (b) that it confuses other software (eg, linters, as Chris admits "<=" would do), or (c) that he needs polymorphic variables such that having the semantics of the operator differ across classes in the union would confuse humans, I think this moots the whole "new operator" proposal, and we can move on to bikeshedding the choice of operator symbol. Yet Another Steve _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/