Python component model

[Michael Sparks]

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>.

Well that's the thing you *do* want since you want the previous
paragraph ;-)
(Or at least a way to adapt component models.)

> 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.

OK, maybe I was being a bit strong - I was merely thinking "lots of
people have something like this already, and I've not seen anyone push
their model as THE model", (even if lots of people like *their* model
:-)

However, I was also being a bit tongue in cheek, though I should have
said unreasonable, not arrogant:
   "...all progress depends on the unreasonable man." -- Bernard Shaw.

What could have some mileage though is proposing a standard way for
these component models to interoperate. What that would look like
(given the wildly different models :), is another matter and an
exercise for the interested reader ;-)

> > 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.

NB, I'm using component model in it's loosest form there.

> > 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 !

You're welcome. Any deficiencies or improvements or suggestions you've
got would be very welcome (I can see some which we're planning on
addressing at some point, but fresh critical eyes are always welcome).

> > 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.

They do, however in particular, Trac's model whilst web oriented
strikes me personally as interesting and PEAK's is applicable, as I
understand it, outside the web sphere. (Enthought was mentioned
elsewhere and is interesting (IMO) for the properties stuff)

If you're interested in event systems as well, it's probably worth
looking at the way a number of pygame applications are written since
there's an event model built into pygame that some pygame apps take
advantage of for custom events and some don't. It's a very different
problem realm to the web systems.

Twisted is worth looking at as well, since it's probably got one of the
more interesting approaches for dealing with essentially event based
systems I've seen.

> 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.

You *may* also want to take a look at picolo as well then - but as far
as I'm
aware it's not actually *used* by anyone. It is in some respects more
like
the kind of component model you describe here. (I personally didn't
find much
useful about their proposal that goes beyond what python already
provides
you) However you might find that and some of the other things on the
following
link interesting: http://www2.lifl.fr/~marvie/software.html

It's worth bearing in mind though that your description above is one
approach
for component based design. A survey of different approaches which you
might find useful:

> Thanks for all the link regarding kamaelia.

Probably went a bit overboard there :)

However I do agree that a visual system is something important, since
not everyone thinks the same way. (I can talk about our system till the
cows come home, show people code, but when I show them the visual
builder, everyone seems to understand).

Regards,


Michael.
--
Michael Sparks, Kamaelia Dust Puppy
http://kamaelia.sf.net/
http://yeoldeclue.com/blog