> > In structure design ... and especially when you design a hardware that > is meant to be automatically converted into verilog or even logic > gates, I personally would really want to have a one-to-one > relationship of the python-objects vs the actual hardware structures. > The granularity is at signal/bit level. This is why I really think > giving a special assignment in python which users could override is > really helpful, rather than having to have this kind of special case: > if you do "self.abc = thing" descriptor mechanism is invoked, but the > very next line if you do "abc = thing" ... nothing will happen. This > special case can be completely removed and having a much better > conceptual consistency if the "<==" assignment operator always behaves > the same, doesn't matter if it is "self.abc <== thing" or "abc <== > thing". >
This seems like a hurdle you're going to have trouble passing... especially given that all the functionality that is required can be provided using existing descriptor behavior. You will need to pretty concretely demonstrate why the special handling of signals in assignment (no matter which operator is the operator of choice) is something the language at large really needs, and why descriptors aren't sufficient. And to be honest, working with a SignalDescriptor class seems like the most explicit and readable approach anyway, given that your stated first preference is to customize/"overload" the assignment operator. Python already provides nearly the exact syntax you want, you are just limited to confining it to your own Signal and SignalDescriptor objects. Comparing this idea to adding a matrix operator: in the latter case, even if you created a Matrix class and customized __mul__ behavior, there were still two competing definitions for how multiplication can occur. So that couldn't be solved through customized classes. In this current case, the problem CAN be solved by pairing a customized Signal and SignalDescriptor. Unless you can demonstrate exactly why that this isn't a workable solution, I think you can expect it to be very difficult to get the buy-in you need.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
