Python component model

[Kay Schluehr]

fumanchu wrote:

> > 4) Custom property and component editors: A component editor can present
> > a property editor or an editor for an entire component which the visual
> > design-time RAD environment can use to allow the programmer end-user of
> > the component to set or get component property values. Normally a design
> > time environment will present default property editors for each
> > component property type, but a component can override this.
>
> This is the hard part. I believe Dabo has done some work in this space,
> but this is where the tight coupling comes in between code and tool, a
> coupling which Python has traditionally resisted.

I do think it's just about presenting component properties and their
types / value ranges. I do think this can be easily achieved using
decorators that might also add the right kind of token for
introspection purposes to the function/method attributes. Descriptors
i.e. customized binding semantics might cover one aspect of
componentization but as I understood Edward he asked for uniform
declarative semantics. Components in this sense are just specialized
objects such as TestCase classes in the PyUnit framework. What I still
do not understand is the reference to "many RAD" tools which is
completely hypothetical to me. The portability of components across
different GUI designers for the same underlying toolkit is a quite
speculative future requirement to say the least.