Python component model

[Edward Diener No Spam]

Diez B. Roggisch wrote:
> Paul Rubin schrieb:
>> "Nick Vatamaniuc" <vatamane at gmail.com> writes:
>>> Python does not _need_ a component model just as you don't _need_ a RAD
>>> IDE tool to write Python code. The reason for having a component model
>>> or a RAD IDE tool is to avoid writing a lot of boiler plate code.
>>
>> It's also so that applications written in differing languages can call
>> each other.
> 
> Nope. Things like CORBA and COM do have that property, but e.g. the Java 
> beans spec has only a meaning inside the VM. Not sure about .NET, but I 
> can imagine there it's the same thing.
> 
> All the languages he mentioned are statically typed, or the component 
> models themselves are. So the component model is basically needed (as 
> others also mentioned) to glue things together, to dynamize that - 
> whereas python is dynamic on the first hand, and actually lacks static 
> typing to infer component properties...

While I understand dynamic typing, I still think it is possible to 
create attributes in a Python component model which could tell a RAD 
tool what type the attribute will encompass for the purpose of 
properties and events. Obviously a "name, type" tuple, among other 
possible information would have to be used. But given Python's amazingly 
flexible type and introspection system, this should be possible.

Of course I am not trying to change the nature of normal Python 
attributes per se at all, and one of the most important things in a 
property-method-event component model is to be able to specify 
properties that are distinct from just normal object data members. So 
one of the most important things in a Python component model would be 
the ability to tag component properties as totally distinct from normal 
Python class attributes or property attributes.

Given that Python already has new-style class properties, maybe another 
name for the component properties I envision is needed to avoid confusion.