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/

Reply via email to