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:
>
> [EMAIL PROTECTED]:~$ 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.
--
http://mail.python.org/mailman/listinfo/python-list
