Python component model

Michael ms at
Tue Oct 10 02:41:52 CEST 2006

Edward Diener No Spam wrote:

> Has there ever been, or is there presently anybody, in the Python
> developer community who sees the same need and is working toward that
> goal of a common component model in Python, blessed and encouraged by
> those who maintain the Python language and standard modules themselves ?

Someone aiming towards a standard to /replace/ everyone else's? That
presupposes a level of arrogance that seems unusual in the python world.
(whilst everyone's proud of their own code and they _generally_ respect
other people's even if it's not their cup of tea).

The WSGI standard could be a form of component model, and has gone through
the PEP process so that might match your criterion. As for component
models, they do exist.

Our component model on the Kamaelia project [1] is one that's heavily
designed around the idea of composition and independent execution of
components and message passing (message passing maps to events for some
sorts of message), 

I wouldn't think of proposing it as the single standard to rule them all
though, for the simple reason every approach has its own strengths. (We do
find the approach extremely useful though)

If you want a quick example of the core ideas, a tutorial aimed around
building a massively simplified core is here:

If you want to see a substantial example, you can look here:
   * - whiteboarding with audio where every client
     is a server. The entire resulting system is also a component.

For something more simplistic:

Something halfway in terms of complexity (a PVR for transcoding everything
broadcast on digital TV):
     (OK, you need to add more channels, but you'd need more CPU's too)

We also have tools for introspecting a running system, and also a visual
composition tool (called Compose) [2] for creating simple systems
graphically, and that, as you say, handles a significant chunk of
dreariness. Suggestions on improving the model and composition tool are
very welcome, code is even more welcome :)

   [2] Sample system created with the newest version of Compose:

       Compose is also a Kamaelia system, and can be found here:

       (bulk of the wiring up is in the bottom of the file - this is an
       interesting example because of the use of Pygame and Tk for different
       parts of the interface where appropriate)

However, off the top of my head, you should also look at Zope's component
model, Trac's component model, Twisted's model & PEAK, and any proposal
to say "this is the solution", needs to be compelling for all of these

Note, they do change where there's a benefit - twisted adopted some
interesting ideas from Zope for example - however the onus on showing the
benefit is on you. (Which if you can do, would be welcome I would expect)
One thing that would probably be very useful would be to identify a way the
various models these projects use can be made to interact better.

The reason I mention //our// model is because we're finding it useful, and
has visual composition, introspection and components have a rich amount of
meta data associated with them, this may or may not fit your criterion.

One of the most "bling" examples we've got right now though (which I
mentioned mainly because it does show reuse up quite nicely) is where we
play Dirac encoded video back onto a pygame surface and then render that
onto a texture that's on a plane spinning in 3D (in realtime):
   * Code:
   * Screenshot:

I've uploaded a collection of other screenshots of various kamaelia related
things here:

You may find the following interesting:
   * (example
     of putting components in places they don't realise)


Kamaelia Project Lead

More information about the Python-list mailing list