Python component model

[Edward Diener No Spam]

Michael Sparks wrote:
> 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.)

I was being funny above. Yes I would like to establish a basic component 
model for RAD development in Python. But surely it need not replace all 
others but could serve at least as a base class for other derived models 
for various environments. That way a developer writing a Python 
component could have it work in these environments as a simple component 
and more complex components, tailored to that environment could be 
created as necessary through inheritance.

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

Bravo, Shaw. Of course by unreasonable I assume Shaw meant those using 
imagination and inspiration along with logic and reason.

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

I do like most of Enthought's notion of properties, which they call 
"traits", no doubt to also distinguish it from Python new-style class 
properties. Their notion corresponds somewhat to the idea of properties 
in Java and .Net.

Essentially a property-method-event component model in Python needs 
component properties and component events, so investigating notions of 
component properties in Python is something I want to do.

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

Are there any URLs you know for looking at these event models ? In 
general an event model for a component must be ideally very flexible, 
which in my terminology means that any Python user-defined class or 
function object should be able to handle any exposed class event given 
the correct callable signature.

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

Again, thanks for the links.