Python component model

Edward Diener No Spam eldiener_no_spam_here at earthlink.net
Mon Oct 9 22:52:36 EDT 2006


Michael wrote:
> 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 reason I would like to see a standard component model for Python is 
so 3rd party developers could create their classes to conform to this 
model and work in any RAD IDE environment which adapts it. That's the 
way JavaBeans work, that the way Borland's VCL component model works, 
and that's the way .Net works. When there are many different component 
models, the 3rd party developer must adapt their components to each 
model for a particular environment.

But far be it from me to want to replace everybody else's model <g>.

By your reasoning above, standardizing anything in software is an 
arrogant proposition. Whereas I look at standardization, when it is well 
done, as a boon to programmers.

> 
> The WSGI standard could be a form of component model, and has gone through
> the PEP process so that might match your criterion.

I do not know what it is but I will look it up.

> 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), 
>    [1] http://kamaelia.sourceforge.net/Home

I will look at kamaelia. Thanks !

> 
> 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:
>    http://kamaelia.sourceforge.net/MiniAxon/
> 
> If you want to see a substantial example, you can look here:
>    * http://tinyurl.com/oqjfb - whiteboarding with audio where every client
>      is a server. The entire resulting system is also a component.
> 
> For something more simplistic:
>    * http://kamaelia.sourceforge.net/Examples/SimplestPresentationTool.html
> 
> Something halfway in terms of complexity (a PVR for transcoding everything
> broadcast on digital TV):
>    * http://tinyurl.com/lvygq
>      (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:
>           http://tinyurl.com/numwk
>        Compose is also a Kamaelia system, and can be found here:
>           http://tinyurl.com/p7z76
>        (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
> projects. 

A standard component model could be used as a base for other more 
advanced needs. Most of those mentioned above seem to involve web 
application frameworks whereas my idea of a component model just assumes 
  the paradigms of properties, methods, and events which may allow 
re-usable components at a base level in any environment.

A particular implementation is certainly allowed to build a more 
complicated idea of a component, through inheritance, from a base level 
component, and this is in fact the way that most components work in 
current component model environments I have mentioned. For instance in 
.Net a control is a component with other added qualities. So while one 
could build components which are not controls, it is necessary to add 
functionality to the base level idea of a component in order to create a 
control.

> 
> 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: http://tinyurl.com/oynxv
>    * Screenshot: http://kamaelia.sourceforge.net/t/Dirac3D.png
> 
> I've uploaded a collection of other screenshots of various kamaelia related
> things here:
>    * http://kamaelia.sourceforge.net/screenshots/
> 
> You may find the following interesting:
>    * http://kamaelia.sourceforge.net/screenshots/Compose.png
>    * http://kamaelia.sourceforge.net/screenshots/KamaeliaOpenGL.png (example
>      of putting components in places they don't realise)
>    * http://kamaelia.sourceforge.net/screenshots/AxonVisualiser.png

Thanks for all the link regarding kamaelia.



More information about the Python-list mailing list