Python component model

[Edward Diener No Spam]

Paul Boddie wrote:
> skip at pobox.com wrote:
>> Edward> My OP was just to query whether a component model existed for
>> Edward> Python, like JavaBeans for Java or .Net for C#, C++/CLI
>> Edward> etc.
>>
>> For those of us who've never used Java, .Net or C++/CLI, a more concrete
>> description of what you were after from the beginning would have been
>> helpful.
> 
>>From vague recollections of the original Java Beans technology, the
> primary "innovation" was to have getProperty and setProperty methods,
> along with things like isCapability and hasProperty, if I remember
> correctly. None of this was really shocking to anyone using Python,
> mostly because Python had __getattr__ and __setattr__ even back then
> for customising real property/attribute access, and Python's run-time
> introspection capabilities were superior to Java's (and probably still
> are).

There is no argument on my part that Python's introspection and metadata 
  capabilities are superior to Java, as well as its potential attribute 
as component property model. In the theoretical Python model I proposed, 
the designer of the component must have the ability to specify which of 
the component's attributes are properties and how this is controlled ( 
via __getattr__ and __setattr__ ? descriptors as someone else suggested 
? other ideas ? ). Merely saying that all of an object's attributes are 
component properties for the purposes of a visual RAD designer can not 
be correct.

I actually think that Java's notion of preoperties in JavaBeans, which 
are just getter and setter functions with a particular naming 
convention, determined by Java as a default, or through an associated 
BeanInfo class, is rather klutzy and much prefer that of .Net or 
Borland's VCL where a particular language construct is used for 
properties instead. Of course with Python's superior metadata abilities, 
a particular new language construct shouldn't be necessary.

> 
> The other innovation was the introduction of standard interfaces for
> listening to and dispatching events, where you implement some listener
> interface and respond to events in order to "care about" those events.
> I don't recall any particularly good mechanisms for connecting beans to
> each other in order to fire off events, although the beanbox (or
> whatever the graphical tool originally promoted was called) and/or the
> IDE is supposed to help you with that part of the work.

The beanbox did nothing to help setup events, event sources, or event 
listeners. It just presented a graphical example of a visual RAD tool 
which could tie event sources to event listeners. It is onerous in 
JavaBeans to connect event sources to event listeners, and takes a good 
deal of manual coding although doing it is easy to understand.

> 
> The groovy 1990s API

1997.

Again Borland's VCL or .Net have much better solutions for events but 
again require language constructs which Python ought not need given its 
strong metadata possibilities to supply a component event model.

> is actually viewable in various places; here, for
> example:
> 
> http://www.doc.ic.ac.uk/~jpc1/linux/bdk-doc-1.0/apis.html

The BDK is no longer supported in the latest version of Java and 
JavaBeans. Instead there is a Bean Builder at 
https://bean-builder.dev.java.net/ .

> 
> Despite the supposedly exciting advances heralded by Java Beans, a
> large part of the technology was just codifying existing practices and
> techniques, but it could be argued that such techniques have been
> superseded by signal/slot mechanisms and more advanced event
> architectures (pioneered by frameworks like Qt and since adopted by
> Gtk, I believe).

I agree and I would want to have a component event model for Python that 
is much superior to the JavaBeans event model in ease of use. A much 
better ideal for component properties and component events is presented 
by .Net, where there are actual language keywords which perform the 
magic. I would guess that Qt and Gtk also follow a better ease of use 
path, perhaps with macros in C++. But Python should be able to do as 
good or better than any of these environments.