design choice: multi-threaded / asynchronous wxpython client?

[bullockbefriending bard]

On Apr 27, 11:27 pm, "BJörn Lindqvist" <bjou... at gmail.com> wrote:
> I think twisted is overkill for this problem. Threading, elementtree
> and urllib should more than suffice. One thread polling the server for
> each race with the desired polling interval. Each time some data is
> treated, that thread sends a signal containing information about what
> changed. The gui listens to the signal and will, if needed, update
> itself with the new information. The database handler also listens to
> the signal and updates the db.

So, if i understand you correctly:

Assuming 8 races and we are just about to start the race 1, we would
have 8 polling threads with the race 1 thread polling at faster rate
than the other ones. after race 1 betting closed, could dispense with
that thread, change race 2 thread to poll faster, and so on...? I had
been rather stupidly thinking of just two polling threads, one for the
current race and one for races not yet run... but starting out with a
thread for each extant race seems simpler given there then is no need
to handle the mechanics of shifting the polling of races from the
omnibus slow thread to the current race fast thread.

Having got my minidom parser working nicely, I'm inclined to stick
with it for now while I get other parts of the problem licked into
shape. However, I do take your point that it's probably overkill for
this simple kind of structured, mostly numerical data and will try to
find time to experiment with the elementtree approach later. No harm
at all in shaving the odd second off document parse times.