design choice: multi-threaded / asynchronous wxpython client?

bullockbefriending bard kinch1967 at gmail.com
Sun Apr 27 11:54:55 EDT 2008


On Apr 27, 10:05 pm, "Eric Wertman" <ewert... at gmail.com> wrote:
> HI, that does look like a lot of fun... You might consider breaking
> that into 2 separate programs.  Write one that's threaded to keep a db
> updated properly, and write a completely separate one to handle
> displaying data from your db.  This would allow you to later change or
> add a web interface without having to muck with the code that handles
> data.

Thanks for the good point. It certainly is a lot of 'fun'. One of
those jobs which at first looks easy (XML, very simple to parse data),
but a few gotchas in the real-time nature of the beast.

After thinking about your idea more, I am sure this decoupling of
functions and making everything DB-centric can simplify a lot of
issues. I quite like the idea of persisting pickled or YAML data along
with the raw XML (for archival purposes + occurs to me I might be able
to do something with XSLT to get it directly into screen viewable form
without too much work) to a DB and then having a client program which
queries most recent time-stamped data for display.

A further complication is that at a later point, I will want to do
real-time time series prediction on all this data (viz. predicting
actual starting prices at post time x minutes in the future). Assuming
I can quickly (enough) retrieve the relevant last n tote data samples
from the database in order to do this, then it will indeed be much
simpler to make things much more DB-centric... as opposed to
maintaining all this state/history in program data structures and
updating it in real time.



More information about the Python-list mailing list