Timer class, to be taken as a model for other classes

I wanted a timer, rather like the Visual Basic object, and I wanted it with no cumulative error. And I wanted it flexible, so I wouldn't have to write another one. I'm very lazy BTW, so lazy that I will go to great lengths to avoid having to write something a second time. Actually, this fits quite well with the "write once, refer often" coding style. I liked the flexibility of the .config() setup style used for Tk controls, so wanted to implement that.

I spent a long time searching for timers, and there seemed to be about 3 basic types, I eventually settled on the threading.Timer repeat call model. I spent far too long battling with freezes in IDLE, before realizing that my timers appeared to run OK standalone, and that IDLE just didn't like threads (I've just installed IPython, and will see how that copes once I've learnt my way round it).

Then I tried to get a flexible configuration, and that's where code bloat seemed to set in. I've tried to manage it back again by making lists of my attributes, and reusing those lists wherever I need them, I hope this class could serve as a pattern for any future classes with the minimum of editing. I understand the duck typing principle of try rather than test, but I prefer to have errors caught at the time I try to configure something, rather than later at the time I try to use it. I've tried to be as duck-like in my tests as possible, hoping to get the best of both worlds. I am not suggesting my tests are bomb-proof yet, I will test them more thoroughly in due course. My test for valid integers isn't quite as smart as I'd want it yet (accept 4, 0x11, '4', '0x11', reject 3.142) (int() covers enough of that ground for the moment), but that is a simpler issue to be tackled later.

My concerns are:

-
Before I use it as a pattern for other classes, have I done a reasonably pythonic job, or am I just kidding myself?

-
There seem to be a lot of lines of support, and very little payload, could the same effect have been achiev

My first impression is that it's overengineered by Python standards. (Or maybe just by my standards, which are a little on the cowboy side.)

Some specific crits:

• Don't use prints for error cases in the config; raise exceptions instead. For

diagnostics that aren't necessarily show-stopping, use the logging
module so that client code can decide how to handle them.

• My initial thought was not to track a callback function for the overrun case, but raise an exception instead, but that's problematic with the threading.

• For a

programmer-facing object, I would never go to so much trouble in
accepting different datatypes. A string is not a number and
pretending otherwise is dangerous.

• If you insist on retaining the

type checking and/or coercion, I would, rather than maintaining three
separate lists, maintain one list of (name,type) tuples, or possibly
a dict of lists keyed by type. But really, self.period = float(period).

• Personally, I feel that kwargs games are for when you're tunneling through Python to an existing API.

Returning usage from config is an interesting idea, useful in the interactive shell... but you still haven't quite explicitly documented the function's behavior in either the usage or the docstring, so a user still has to RTFS, and you've obfuscated the source with a lot of parameter management code that isn't doing useful work.

StackExchange Code Review Q#12995, answer score: 2