Python component model

[Edward Diener No Spam]

Kay Schluehr wrote:
> 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. 

Uniform in the sense that a visual RAD tool introspecting a Python class 
would be able to say that s type X is a component property and type Y is 
a component event, and everything is is just normal Python code which 
the RAD tool can ignore.

> Components in this sense are just specialized
> objects such as TestCase classes in the PyUnit framework.

Totally agreed. But the common functionality they add is valuable to 
visual RAD tools.

> What I still
> do not understand is the reference to "many RAD" tools which is
> completely hypothetical to me.

You are right that I should not have mentioned this without experience 
with the many Python tools, notable Python web page development 
environments, which are out there.

> The portability of components across
> different GUI designers for the same underlying toolkit is a quite
> speculative future requirement to say the least.

It's been a success in the Java world with JavaBeans and EJBs within 
environments like Eclipse, NetBeans, JBuilder, and others; and its been 
a success in the .Net world with .Net components within Visual Studio, 
Borland Development Studio, and potentially others, so ideally it could 
be a success in the Python world.

I believe the only knock against Python, as opposed to Java or .Net, is 
that it does not present enough ease of use environments to creating 
large scale applications, whether Linux, Windows, or Web applications. I 
believe part of that reason is because Python developers who, whether 
they wanted to distribute their classes for free or want to sell them 
for a profit, are presented with endless technologies built with Python, 
each one demanding a slightly different approach to class reusability, 
are reticent to develop their ideas for many different environments.

Wanting a common PME component model is a way of saying that Python 
class developers can develop their classes as components and at least at 
the base level can expect them to work flawlessly in any Python 
environment. I am NOT against a particular environment building further 
requirements on top of a common Python component model, and in fact 
would expect it in many cases. But given inheritance in OOP, and in 
Python of course, this might be as easy for me as deriving a new class 
from my particular base class component for a particular visual RAD 
development environment, adding the extra function needed onto my 
derived class, and away we go.