Thanks. I'm onboard with the changes Marc and you, as below, suggest,
and will very, very likely grab onto ConfigObj. I'll look into Quick
Edit. I use Snagit to screen capture. One of the most useful tools I've
come across in a long time.
The real meat to this code is not implementing a config file, although
I believe it warrants one. The real meat is adding analytic
capabilities. The program provides a very good interface between the
hardware and the user, but has no analytic power.
What's happening here is the program drives a video camera to capture
fireballs (bright meteors). It does almost nothing more, but has a few
administrative functions like deleting false images and making a
composite of the video frames. The most elementary elementary analytic
calculation it might be able to make for a single observer is a rough
estimate of the distance to some part of the meteor trail. The deepest
calculation it might be able to make is to actually calculate the
trajectory of the trail and determine a possible geographic fall point
for the object. This requires calculations from two observers.
Nevertheless, neither is available, and they can be implemented. That's
where I'm headed. The author had his hands full getting this code out,
which is all to his credit. I'm trying to take it to the next step.
He's a plenty busy guy.
Martin Walsh wrote:
Marc Tompkins wrote:
Also - config_var_list is a tuple of lists. (I'm guessing you intended
to make it a list of lists - that's what the name indicates, after all -
but putting it between "( )" makes it a tuple.)
Sound advice, but a subtle clarification is warranted I think. It's the
comma(s) that make a tuple not the parens (and an absence of square
brackets, I suppose). Consider the following:
In [1]: a = (1)
In [2]: a
Out[2]: 1
In [3]: type(a)
Out[3]: <type 'int'>
In [4]: b = (1,)
In [5]: b
Out[5]: (1,)
In [6]: type(b)
Out[6]: <type 'tuple'>
In [7]: c = 1, 2, 3
In [8]: c
Out[8]: (1, 2, 3)
In [9]: type(c)
Out[9]: <type 'tuple'>
...
Wayne, I second Marc's advice that you're making it hard on yourself.
Understandable to a degree, if you are trying to avoid major
modification to inherited code.
But, loading and saving configuration data is a 'solved' problem in that
there are many choices of ready-made tools to help you accomplish the
task. And, I don't see anything in your description that would indicate
a custom solution is necessary -- except perhaps for the learning
experience, almost never a bad idea, IMHO.
Marc has already pointed out ConfigObj, which is excellent, but I
thought I would also suggest ConfigParser -- part of the standard lib,
if a bit less feature-full.
Back to your original question, and I'm probably overstating the obvious
at this point, but the underlying problem is that the operation causing
the exception is expecting a datetime.time object and getting a str. So,
it's less about adding a strftime attribute to the str object, and more
about 'converting' the str into a datetime.time object.
Short of re-writing for ConfigObj (which provides a type conversion and
validation mechanism), or pickle, or similar -- you'll need to work out
how to convert between str and datetime.time. Here are some (untested)
examples:
def time_to_str(t):
return t.strftime('%H:%M:%S')
def str_to_time(s):
h, m, s = [int(u) for u in s.split(':')]
return datetime.time(h, m, s)
HTH,
Marty
PS. You can avoid posting images of tracebacks by enabling 'Quick Edit'
mode in your windows command prompt. More info here:
http://support.microsoft.com/kb/282301
_______________________________________________
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
--
Wayne Watson (Watson Adventures, Prop., Nevada City, CA)
(121.01 Deg. W, 39.26 Deg. N) GMT-8 hr std. time)
"Nature, to be commanded, must be obeyed."
-- Sir Francis Bacon
Web Page: <www.speckledwithstars.net/>
|
