What's wrong with the use of attributes in this case and how
would you write your interface?
I think I'd add a change_temperature_to method that accepts the target
temperature and some sort of timing information, depending on how the
rest of the program and/or thread is structured.
Hmmm. I wonder if this is mostly a question of how the
process decomposition occurs. I think in objects ("thingys
with state") whereas you think in tasks ("thingys that do stuff")?
I say that somewhat surprisingly in that I'm not a deep OO
person - functions are fine with me and I don't like the
Java/Ruby "everything is in a class" world view.
It might turn into two
or three methods, depending on whether I can afford to block while
waiting, or what kind of intermediate feedback and/or error handling I
want (or one method with some carefully chosen default arguments).
In the case I'm hypothesizing (haven't worked with a temperature
controller in about 15 years) it's hard to put a layer above
everything because there could be so many different protocols
(chemical protocols, not I/O ones) with different rates. Eg,
it could be an exponential decay, or step-wise approximation
The note about errors is interesting. For example, if the
cable to the controller was disconnected then someone, especially
someone used to memory lookups for attributes, might not expect
to possibly raise an I/O error exception. On the other hand,
at the C level that could be memory mapped I/O, so that
int x = temp_controller.current;
could also have all sorts of side effects. That case
is dangerous in C because of its poor exception mechanism.
I think in Python it's much less of a problem.
I don't know how that device driver works, but it might look something
def change_temperature_to( self, target, seconds_between_checks ):
print 'target temperature:', target
current = read_the_temperature_from_the_device( )
print 'current temperature:', current
if abs( current - target ) < 0.1:
time.sleep( seconds_between_checks )
Your "tell_the_device_to_change" is my "self.target" and your
"read_the_temperature_from_the_device" is "self.current_temperature".
In some sense it comes down to style.
BTW, had I done this for real I would have two layers, one
which is communications oriented ("send 'get current temperature'
message to device") and my object model which uses the messaging
I think part of my thinking
comes from my old Pascal days, when it made me cringe to think that
"x:=b;" might actually execute a subroutine rather than just copy some
To give a more recent example for me, which I covered here some
years back, I wrote an OO interface to an "OO-ish" C library
for doing chemistry. In the data model, atoms have an atomic
symbol, a charge and a list of bonds (and many other things).
Bonds have a bond type and the two atoms at the ends of the bonds
(and many other things).
I liked being able to say:
print atom.symbol, "with charge", atom.charge, "has", \
for i, bond in enumerate(bonds):
print "bond", i, "has type", bond.bondtype
To me this is a very natural way of querying the data and
traversing the data structure.
Now underneath the covers it looks like this:
atom.charge fails so use __getattr__(atom, "charge")
__getattr__ uses a dispatch table to get the underlying C function
which is "dt_getcharge"
where "handle" is the handle used by the C library.
I figured though that this example might be more esoteric
than my PID controller example, though in retrospect it
looks like it might be a better justification.
dalke at dalkescientific.com