Diez B. Roggisch wrote: > Paul Rubin schrieb: >> "Nick Vatamaniuc" <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
