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. -- http://mail.python.org/mailman/listinfo/python-list
