Lie <Li...mail.com> wrote: >> This of course means that there has to be another >> thread active to actually do the i/o on a periodic basis, >> gathering the outputs and writing them out, and reading >> the inputs and scattering them to the various named input >> bits > >Not necessarily. You've mentioned two ways.
True. >> I would even not mind if I have to write: >> >> if e_stop(): >> put_everything_off() >> >> or: >> >> set(push,1) >> > >PS: Umm, a little bit off note: set is a built-in name, I'm a little >confused whether you meant on creating a "set" or setting the push bit >to 1, if the latter case it might be better to use set and clear >instead of passing a second parameter (and also to choose another >name). > True. this was a brain fart - should have been setbit or something. >.Alternatively, there is one more way: >if bb.e_stop: > bb.e_stop = 0 >where bb is some kind of "property bag" and .e_stop is a "property" >instead of an "instance member". > what is the advantage? 8<----------------------------- >Rather than directly using getters and setters, I'd go with property. >It (usually) makes a cleaner external interface of the class. And for >the mess of having to write lots of boilerplate codes, you _could_ >dynamically generate the boilerplate code from a dictionary (of name >to bit position) and currying (or something to that effect). >Alternatively, you could also do some magic with getattr and setattr. I am not too sure I know how... - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
