On Oct 11, 5:27 am, "Hendrik van Rooyen" <m...@microcorp .co.zawrote:
Not necessarily. You've mentioned two ways.
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).
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".
>
>
See above explanation - see also a recent thread here
about "Python string immutability broken" where I posted the
prototype ctypes code, if you are really interested...
>
>
>
>
>
Not necessarily unnecessary - the getters and setters could be
used to actually do the i/o to the relevant card when anything
makes an access to one of the bits on the memory representation
of that card - that would obviate the necessity for a second thread...
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.
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
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
I would even not mind if I have to write:
>
if e_stop():
put_everything_ off()
>
or:
>
set(push,1)
>
>
if e_stop():
put_everything_ off()
>
or:
>
set(push,1)
>
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).
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".
This approach has the advantage that you can
add a ninth "dirty" bit to indicate that the "byte"
in question needs to be written out.
add a ninth "dirty" bit to indicate that the "byte"
in question needs to be written out.
What do you mean by "written out" to where?
See above explanation - see also a recent thread here
about "Python string immutability broken" where I posted the
prototype ctypes code, if you are really interested...
>
Is there not some OO way of hiding this
bit banging complexity?
bit banging complexity?
foo & bar is complex? So you want to replace foo + bar
as well with something? ;)
as well with something? ;)
Using getters and setters? - I tend to go "tilt"
like a cheap slot machine when I read that stuff.
like a cheap slot machine when I read that stuff.
Getters setters? Where would that improve the situation
beside having to write lots of unneccessary code?
beside having to write lots of unneccessary code?
Not necessarily unnecessary - the getters and setters could be
used to actually do the i/o to the relevant card when anything
makes an access to one of the bits on the memory representation
of that card - that would obviate the necessity for a second thread...
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.