Python component model
Diez B. Roggisch
deets at nospam.web.de
Tue Oct 10 16:02:56 CEST 2006
> 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.
The amazing flexibility stems from the fact that it is _runtime_. This is
_exactly_ the difference between static and dynamic typing.
If a static analysis (_not_ importing the module, which can trigger
arbitrary code being run!!!) is supposed to deliver the component
architecture, you are either introducing static typing, or get into the
danger of lose coupling between declaration and implementation, rendering
the whole thing pretty useless.
Of course, with a bit of discipline, you can create such a introspection
facility that offers its properties after a mere import, see ZOPE
interfaces for example.
But in the end, it boils down to declaring stuff for that purpose alone, and
introducing static typing, whereas other languages declare typing for their
own needs, and add the component model upon that.
And then you lose a _lot_ of what python makes powerful, for a very doubtful
More information about the Python-list