Efficient Bit addressing in Python.

Lie Lie.1296 at gmail.com
Fri Oct 10 14:12:23 EDT 2008


On Oct 11, 5:27 am, "Hendrik van Rooyen" <m... at microcorp.co.za> 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.

> 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).

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.
>
> > 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?
>
> > foo & bar is complex? So you want to replace foo + bar
> > as well with something? ;)
>
> > > Using getters and setters? - I tend to go "tilt"
> > > 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?
>
> 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.



More information about the Python-list mailing list