Hello there, I use NumPy/SciPy to process telemetry, producing some metrics that I plot with matplotlib. Well, I want to package my scripts into a sort of all-wrapping application, i.e, the user just calls the app, selects which metrics to produce and waits to obtain the plots, without being exposed to anything more dangerous than a zoom button.. The scripts that produce these metrics use Scipy/Numpy functions that operate on data conveniently converted to numpy arrays. They're quite specific, and I tend to produce/tweak a lot of them. So, to fit in this application someone suggested I programmed 'interfaces' (in java jargon) to them - that way I could develop the whole wrapper application without giving much thought to the actual number-crunching bits. Problem is, I learnt numerics using Fortran, and though I understand the idea of objects, I have quite some difficulty imagining the 'patterns' that allow OO to be so flexible. So I was wondering if anyone experienced with OO Numerical computing could provide some pointers. For context, here are my thoughts: 1. the core of the application is responsible for interaction with the outside world. Crunching blocks are provided data and return matplotlib objects that go into GTK. To write procedures that abide to these parameters is my first (fortranic) impulse. But then I need to change the core everytime I add a procedure, and I'm limited to numpy-IN/matplolib-OUT. 2. if I could force every analysis procedure to be a class that implements its own data retrieval and outputs matplolib objects, my core no longer controls the whole communication with the outside world. And i still have to edit the core everytime a new analysis is required. A very interesting thing is that with these classes I could create new objects with different attributes, rather than pass a host of parameters to a procedure.. So, I'm a bit at odds with this brave new world I discovered. I'd be quite grateful for pointers on literature or examples that more or less lead to a solution. So far my searches have justified the need for objects, but not helped address this modularity requirement... Cheers, Renato