Python component model

[Edward Diener No Spam]

Robert Kern wrote:
> Edward Diener No Spam wrote:
> 
>> There's nothing wrong with Python's introspection. In fact Python's 
>> facilities in this area and its support for metadata are stronger than 
>> any of these other languages ! However there is no common component 
>> model which specifies that X is a "property" or Y is an "event" of a 
>> Python class which can be visually manipulated at design-time and 
>> automagically set at run-time, so that any given Python RAD visual 
>> environment will treat a Python class, specified as a component, in 
>> exactly the same way. Also in these other languages, a component is 
>> different from a class in that a component is recognized in a 
>> particular way, often so that the component can interact if necessary 
>> with its container and/or visual site.
> 
> You'll definitely want to take a look at Enthought's Traits (disclaimer: 
> I work for Enthought). I'm supposed to be on vacation now, so I'm not 
> going to give you the full rundown of Traits and Traits UI, so I'm 
> simply going to point you to the page we have about it:
> 
>   http://code.enthought.com/traits/

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.

> 
> You can talk to the rest of the Enthought crew on the enthought-dev 
> mailing list if you have any questions:
> 
>   https://mail.enthought.com/mailman/listinfo/enthought-dev

Already subscribed. Thanks !