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
[email protected]
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/