Python component model

Tue Oct 10 04:05:16 EDT 2006

Edward Diener No Spam wrote:
> 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.

Python does not _need_ a component model just as you don't _need_ a RAD
IDE tool to write Python code. The reason for having a component model
or a RAD IDE tool is to avoid writing a lot of boiler plate code.
Python is terse enough that boiler plate code is not needed, just type
what you need into an editor. It seems that you talk about Python but
you are still thinking in Java or C++.

At the same time one could claim that Python already has certain
policies that makes it seem as if it has a component model. Take a look
at the "magic methods". For example if a class has a __len__ method, it
is possible to use the len() function on an instance of that class. If
a class has the  __getitem__ then indexing can be used on that class's
insance. Then Python has properties (see
http://www.python.org/doc/2.2.3/whatsnew/sect-rellinks.html).  Just by
inspecting the object one can tell a great deal about them (even read
the documentation if needed, by using the __doc__ attribute).   What
other standards would you propose for the core language?