On Wed, May 29, 2019 at 4:43 PM Ricky Teachey <ri...@teachey.org> wrote: > > Seems like this would do it (note: `in` can't actually be a variable): > > class A(HDL): > # A is now an HDL namespace - all members have signal behavior > def __init__(self, in, o1, o2): > self.in = in # descriptor > self.o1 = o1 ; self.o2 = o2 # descriptors > def process(self): > # is self.in, self.o1 and self.o2 are still descriptor here to be > used? > # ^ yes, all of those are SignalBehavior descriptors if A is > subclass of HDL ^ > > class C: > # depending on behavior desired, C could be HDL namespace, too > def __init__(self, in, out): > # these work, but probably are not needed: > ns.in = 0 > ns.o1 = 0 > ns.o2 = 0 > a = A( ns.in , ns.o1 , ns.o2 ) > # ...you can just pass the values to A directly as long as > # A (or HDL) knows what to do with arbitrary in and out values: > a = A(in, out, out)
The plus side of this approach is that you do not even need to create/declare signals, and you still can if you insist doing so. And you actually can enforce all of HDL-type of classes to have only signal-type object attribute, this is actually another good feature of it. I start to like it. To be completely honest (sorry again for my paranoia), this only works e.g. for class A(), if you do self.signal, you still cannot have local signals e.g. in __init__() you can not have local_signal without self, so is in process(). This means, for a middle-sized class implementation, you will start to worry about name space collisions pretty quickly among all the class methods. Information is no longer perfectly localized but spreading across all over your class (and its parents ... which probably in a different file ...). thoughts? _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
