Python component model

Edward Diener No Spam eldiener_no_spam_here at
Sat Oct 14 12:00:23 CEST 2006

Peter Wang wrote:
> Edward Diener wrote:
>> It looks as if traits is an attempt to create a "property" in the
>> component terminology which I originally specified. I will take a look
>> at it.
> Traits is frighteningly similar to the requirements that you laid out
> in your post (the example for Skip), including delegates!  I would like
> to point out, however, that traits is a *general* component framework
> for python that facilitates implementing the observer pattern and a
> higher level of introspection.  It can be used to build applications
> that have no visual interfaces at all, but wish to benefit from the
> "reactive programming" style that componentized, event-based
> programming encourages.  (induces?)

Thanks for the explanation. I was too quick in seeing Traits as only a 
version of properties without realizing that it included much more.

> Traits UI, which Robert only alluded to, is actually very much the sort
> of RAD environment you have described.  It builds upon the component
> model, and uses introspection to automagically create nice widgets for
> your model, but adds mechanisms for specifying controllers, customizing
> behavior, and generically composing complicated forms from simpler
> ones.  There is even a visual "builder" tool for it called VET that
> closely resembles Delphi/C++ Builder.  (The VET itself is, of course,
> written using Traits UI.)

I have downloaded both Traits and Traits UI and will look at both.

> Envisage, the plugin application framework, can use the traits
> component models and the TraitsUI interfaces to roll out very dynamic
> applications, whose underlying models are all live components that can
> be scripted, twiddled with from an embedded Python shell, etc.
>> Already subscribed. Thanks !
> Please contribute ideas or ask conceptual questions!

It would be easier for me if you could get an NG somewhere for 
Enthought, perhaps on GMane, since I always find mailing lists much more 
clunky than a good NG. But that is up to Enthought.

> Oh, and disclaimer: I also work at enthought. :)

That's fine. It is the ideas about a PME component model for Python in 
which I was interested, no matter where it originates. Thanks for the 
encouraging reply.

More information about the Python-list mailing list