Edward, This isn't in response to any specific one of the 100+ posts on this thread, but I justed wanted to encourage you to continue your investigation into Python component models and maybe looking for some common ground between them. Frequently the individual developers are too heads-down on working on their own things to do a broad survey, so I think this would be very useful indeed.
I wouldn't have felt it necessary to post this except for the large number of posts along the lines of "foo.dict is introspective enough for me!". I think you might have an easier time evangelizing the principle of component-oriented programming (or "event-based", or "reactive", or whatever) if you separated it from the notions of RAD UI development. There is a very large difference between writing components and writing objects, and it seems that most people arguing "python doesn't need components" don't see this distinction. For me, it's the difference between writing "live" objects and "dead" objects. Live objects not only encapsulate implementations of an interface with some state, but they also encapsulate handling of events, i.e. responses to changes in their environment. Dead objects have methods but there has to be a function somewhere that knows which dead object to call with what parameters at exactly the right time. (The only mechanism for managing this complexity is to create ever more functions at ever higher levels of abstraction, or to have a proliferation of nebulously-defined "manager" objects.) IMHO once you cross this chasm and are able to model your problem domain with live objects that go off and automatically respond to the runtime environment and Do the Right Thing, it's very hard to go back to a dead object mindset. I can understand, however, that until one makes this leap, it might seem like an academic and useless distinction. -peter -- http://mail.python.org/mailman/listinfo/python-list
