Python component model

[Edward Diener No Spam]

Tim Chase wrote:
>> There's no doubt that Python's excellent introspection mechanism 
>> allows an outside RAD-like tool to inspect the workings of any Python 
>> object. But that does not make it a component model in my original use 
>> of the term on this thread. A RAD tool needs to know what properties 
>> and events within a class can be manipulated visually, and it needs to 
>> be able to serialize those properties and events so that they are set 
>> at run-time automatically once an object is created.
> 
> A little visual inspection of some objects:
> 
> tim at oblique:~$ python
> Python 2.3.5 (#2, Sep  4 2005, 22:01:42)
> [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> class Person(object):
> ...     def __init__(self, name, age=None):
> ...             self.name = name
> ...             self.age = age
> ...     def whoami(self):
> ...             if self.age is not None:
> ...            return "%s (%i)" % (
> ...                self.name,
> ...                self.age)
> ...             return self.name
> ...
>  >>> p = Person("Sandy")
>  >>> [s for s in dir(p) if not s.startswith('_') and 
> callable(eval('p.%s' % s))]
> ['whoami']
>  >>> [s for s in dir(p) if not s.startswith('_') and not 
> callable(eval('p.%s' % s))]
> ['age', 'name']
> 
> Thus, you have the ability to find an object's methods/events (things 
> that are callable()), and its properties (things that are not 
> callable()).  Any "RAD" tool that wants can pull these properties, just 
> as my command-line RAD tool can ;)

Not all attributes are component properties in typical Visual RAD tool. 
In most visual RAD tools which I have used a component property is a 
publicly exposed type/name which may or may not have the backing of an 
actual data member and does have a function to get the type's value if 
the property is readable and does have a function associated with it to 
set the type's value if the property is writable. This is very close to 
the class properties in Python. The difference is that normally a type 
must be associated with a property whereas in Python, as I understand 
it, the type of a class property is unknown.

Furthermore by a component event I do not mean methods on the event 
creator's side but rather an event source. This would look something 
like a tuple of callable functions of a particular signature to which an 
event sink could add an event handler so that when a particular event 
occurred on the event source the event handlers added to the event 
source would each be called.

> 
> As for serializing them,
> 
>  >>> import shelve
>  >>> d = shelve.open('tmp/stuff.shlv')
>  >>> d['person'] = p
>  >>> p = 'hello'
>  >>> p
> 'hello'
>  >>> p = d['person']
>  >>> p.whoami()
> 'Sandy'
>  >>> p.age = 42
>  >>> p.whoami()
> 'Sandy (42)'
>  >>> d['person'] = p
>  >>> d.close()
>  >>> p = 'hello2'
>  >>> p
> 'hello2'
>  >>> d = shelve.open('tmp/stuff.shlv')
>  >>> p = d['person']
>  >>> p.whoami()
> 'Sandy (42)'
> 
> which seems to work fine for me.  This can be used for creating all 
> sorts of flavors of objects at design time, storing them, and then 
> restoring them at runtime.

I realize that Python has excellent abilities in all these areas, 
including serialization. But a component model for serialization must 
not only have the ability of serializing and deserializing all of the 
component's data, as well as any base classes, it must also have a means 
of allowing the class itself to specify which data needs to be 
serialized and which not, as well as allow for the class to seriliaze 
all or part of its own data.